Repository navigation
Strict type-checking on a per-file basis "@ts-strict" #28306
Description
Activity
- addedSuggestionAn idea for TypeScriptAn idea for TypeScriptIn DiscussionNot yet reached consensusNot yet reached consensus
on Nov 2, 2018 Would love to see this feature implemented as well. We have quite sizeable project and going "all strict" is not an option right now.
Reacted by Josh Manning, infacto, Robert Shecter, Kyle Wascher, Matthias, Tom Andza, Kirill Taletski, Debmallya Bhattacharya, Benny Neugebauer, Michael Fry and 39 moreWorth mentioning.... that I ran across another project (unfortunately I forget which one right now) that had this same need. Their workaround was to use a separate tsconfig file and run TWO builds. The first build was NOT run in strict mode and was responsible for the actual compilation. They would then run a SECOND build using a tsconfig file that whitelisted specific files that were ready to be compiled in strict mode. The second build had noEmit = true, and was used ONLY for type-checking. I still think it's much nicer to have this supported natively, but wanted to at least document the workaround in the meantime.
Reacted by Andreas Klöber, Abraham White, Lukas Elmer, Andy Ferris, Josh Manning, Damien Leroy, Robert Shecter, Nicholas Main, iPherian, Kirill Taletski and 9 moreWe tried to implement this with "local"
tsconfig.json-files extending the maintsconfig.jsonwith the strict compiler option and including only specific files or all files within and below that folder, e.g.{ "extends": "../../tsconfig", "compilerOptions": { "strict": true }, "include": [ "./**/*.ts" ] }together with the following npm scripts
"tsc-local-tsconfigs": "errors=$(find src/app -name tsconfig.json | xargs -I % sh -c 'tsc -p % | grep error'); echo \"$errors\n\"; [ -z \"$errors\" ] || exit 1;",
The latter we execute on CI to ensure all files specified in local
tsconfig.jsonand their dependencies can be compiled with those settings.
When viewing one of those files in VS Code, the editor automatically uses thetsconfig.jsonfile closest to that file that has matching include/exclude patterns, so errors are shown immediately.Reacted by Aakash Malhotra, Alex Tsoi, Ryan Rabello, Yury, jameswassink, Robert Shecter, Nicholas Main, Dominique Rau, Kosmas Papadatos, Andrew Chung and 10 moreReacted by Will Cullen, Anton and Patricio Ezequiel Hondagneu RoigAnother example when it can be useful.
I came to a project where TypeScript has been adopted but I found that the team disabled one of strict checks (say"strictFunctionTypes": false,).
The reason (if I set it to true) turns out to be in bad external typings that were used in another (relatively small) part of project. So to avoid this check in a certain place of a large project and to do not introduce castings / any type and etc. they disabled strict check at all.
A better approach would be to disable/enable on per file/per directory basis.
Actually tsconfig hasreferencesfield, but it involves changes in how the project build procedure works AFAIK (it can be undesirable). Maybe a similar field should be introduced, but that specifies what overrides are applied per directory.Reacted by Robert Shecter, Josh Vlk, Guilherme Simoes, Cody Casterline and codethiefWhile this would be really awesome in some cases, I've started to use Betterer so that we can progressively improve our code base and avoid regression because a given flag is turned on locally to do some fixes and then off before pushing.
Here's an example: https://dev.to/phenomnominal/stricter-typescript-compilation-with-betterer-dp7
Reacted by Robert Shecter, Yannic, Willy Camargo, Denis Pshenov, Josh Vlk, gingerr and Josephine LiangEqually, it would be good to be able to turn it on globally, and then disable for specific files.
Reacted by Bohdan Moskalevskyi, Petri Laine, Peyman Khanjan, Seva Arkhangelskiy, Nicholas Main, klr, Jared Kells, Ben Rogers, Kevin Chavez, David Mehren and 30 moreIn our case, we have a huge app that was written years ago with no strict mode.
Today I want to use strict mode for cleaner code and fewer runtime errors.
But we can't activate it, otherwise the code would shine like a Christmas tree.
It is not very economical to convert all the code at once. It's too complex.
So strict mode per file would be great. ...Reacted by Bohdan Moskalevskyi, Alex Krolick, Peyman Khanjan, Fabrice Pomata, Seva Arkhangelskiy, Devan Farrell, Nicholas Main, Purin, Dustin Kane, GannonCombs and 19 moreI agree, there is no way we can migrate to strict mode in one swoop, we need to be able to do that on a per file basis.
Reacted by Devan Farrell, Dustin Kane, Joseph Wheaton, Kevin Chavez, C. Bernold, scaleflake, Kevin Mathmann, David Caetano, Tyreece Rozycki, Alex Hughes and 1 moreI would love this, or at mainly a way to turn off strict for a particular file.
that way I can inforce team not to ever turn off scrict for whole project, just if something must get rushed to production they may use to send in a Merge request with stricted turned off for the one file they are rushing.
Reacted by Dustin Kane, scaleflake and OceanDwellerReacted by cseickelTheNickmaster21 commented
on Feb 22, 2021 More actionsThis feature would be great. We recently converted a medium sized project to strict mode and it was a huge endeavor. We are glad we made the change but there is no way we could do the same thing on our larger projects any time soon. We would love to have this as a mechanism to use strict mode on new development. This would also be great when slowly converting a project.
Reacted by James, Günter Zöchbauer, Pete Richardson, Kevin Chavez and Kevin MathmannI have a use case that may help justify this. I am using gRPC to generate .ts and .d.ts, but then I am using tsc to compile everything into a dist. The generated files must have strict = false in tsconfig, but the files I write I want to to have strict = true in tsconfig. It would be ideal if there was a way to have a tsconfig.override.json inside of the dir that holds those protoc-generated files that tells the global compile process "hey, these files should use these other rules"
While there are no built-in features like this in Typescript, we've created typescript-strict-plugin which allows you to turn on strict-mode in specific files or routes.
Hope it helps!Reacted by Bernardo Rubín, Wayne Cui, Andrew Nester, Finn Merlett, gingerr, shahul01, Steffen Schroeder and Elvis NievesReacted by Bernardo Rubín and Finn MerlettReacted by Stoyko Stanchev, klr, Jarosław Glegoła, Kirill Taletski, Ole Jørgen Brønner, Rafał Łużyński, Leo Chiu, handerss-spotfire, Bernardo Rubín, Vatsal Patel and 6 moreReacted by Bernardo Rubín, Finn Merlett, gingerr and hlovdalReacted by Steffen Schroeder and Denis SmirnovIs there any update on disabling strict mode for specific files?
13 remaining items
- added a commit that references this issue
on May 24, 2022 - added 4 commits that reference this issue
on May 25, 2022 - added a commit that references this issue
on May 30, 2022 - added a commit that references this issue
on Jun 2, 2022 See also #31035, which has a WIP PR: #49886
The PR's demo is exactly what this issue is asking for, I think. Wesley Wigham (@weswigham)
(Maybe this is a dupe? Or the other way around?)
Reacted by Devan Farrell, Timothy Baumgartner and georgetzlpOh, I need this so bad 😢.
Reacted by dominictobias, Elliot DeNolf, Tobias Pickel, Dan Strokirk and Alesandro FerrariI haven't tried it but I saw this TS plug-in shared. https://github.com/allegro/typescript-strict-plugin
Reacted by Daniel L, Igor, Nick Ng, Rob Lucha, Tobias Pickel, codethief and Sudhanshu Pandey👍
Reacted by Tim, David Bednarski, David Pohan, Karol Żuraniewski, Nick Good, Johannes Weih, DanilKazanov and DavidTo solve the problem of migrating to strict type checks, I created @selectel/ts-check.
In our project, we use separate configurations for building and type checking in IDE with strict mode. The utility is used in the CI/CD pipeline to check types of changed files in strict mode, like in the IDE.
Reacted by Nelson Martell and Evgenii PosokhinI haven't tried it but I saw this TS plug-in shared. https://github.com/allegro/typescript-strict-plugin
Thought I would leave a comment here for anyone trying this in 2025. Plugin does not seem to work. It does not recognise the preprocess comment so enabling strict mode just enables it across the entire codebase.
Reacted by Fabrice PomataI think this will be less relevant with TypeScript 6.0, when
strictistrueby default:https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-beta/#simple-default-changes
- For a JavaScript project that is already type checked or for TypeScript projects, this only will be relevant if you intentionally set
stricttofalseand then still want to enable strict check on a file basis - For a JavaScript project that does not enable codebase-level type checking,
// @ts-checkwill enable strict checking, and you do not need any additional flag to enforce strictness
- For a JavaScript project that is already type checked or for TypeScript projects, this only will be relevant if you intentionally set
I think this will be less relevant with TypeScript 6.0, when strict is true by default:
Well, yeah, if you have already have strict type-checking enabled, you're obviously golden. That was already the case when the present ticket got filed almost 7½ years years ago. But the whole point of the ticket is that for existing projects
[enabling] strict mode for the entire project is a daunting task that presents a barrier to adoption
So that's why one needs to be able to do this incrementally, on a file-by-file basis.
Reacted by Ben Morton, Steffen Schroeder, Alex Tsoi, Luke and Totati
Search Terms
strict per file
Suggestion
Currently in the process of converting a moderate-sized javascript project to typescript. Would love to be able to enable strict type-checks on a per-file basis.
Use Cases
Enabling strict mode for the entire project is a daunting task that presents a barrier to adoption (and using typescript without strict mode turned on is like locking the doors on a convertible....it's probably better than nothing, but it's not gonna keep you safe).
Examples
Checklist
My suggestion meets these guidelines: