Allow for highlighting of TypeScript strictness features NOT via tsconfig

[BPapp-MS]

It is a notoriously difficult problem to begin enforcing TypeScript's stricter rules in large codebases -- rules such as strictNullChecks, noImplicitThis, noImplicitAny, etc. add safety and scalability to TypeScript codebases, and many of those who maintain codebases have the goal of someday removing the errors that would appear if their TS repositories began enforcing those rules
(here is post about the various TS strictness features). After a team decides that they want to enforce stricter rules, there's a period before they can compile with those rules, and in that time they want to stop introducing violations of those rules, and probably want to see where violations already exist in the codebase.

Currently, the only way of highlighting places where these rules are being broken, is by configuring the tsconfig.json at the root of the repo to enable these rules. Obviously, if you're dealing with a big repo with a large number of contributors this will probably result in many new errors that can't be solved overnight, if you don't define a new tsconfig to compile with. VSCode's use of the tsconfig.json file at the root of the repo is inflexible, and it's not a graceful solution at all to have to create multiple tsconfig files to work around this. Many tools such as Jest, ESLint, API Extractor, and TSDoc rely on the tsconfig, and making sure they're using the correct one can be a headache. And if you have some tools, such as Heft, which is similar to VSCode in not being able to specify an alternative tsconfig.json, then all of a sudden you must choose between the functionality of one or the other.

Making repositories stricter is a hard problem. When VSCode's own repository phased-in strictNullChecks, they created another tsconfig file with strictNullChecks enabled, named tsconfig.strictNullChecks.json. They added the entire repo, file-by-file, into the new tsconfig fixing strict-null problems as they went. In order to prevent regressions, they incrementally built with this new tsconfig to make sure that no new strictNullCheck errors were appearing. All the while, they were presumably not able to see the rule violations in the editor itself, because the strict null checks were still disabled by the tsconfig.json file at the root of the repo. So, additionally, any files outside of the scope of the tsconfig.strictNullChecks.json could have been invisibly gaining violations of the rule while other developers were working on eliminating them.

Type-strictness options belong to a special class of TS configuration options: rules which you might want to be warned about, without having to enforce in the actual compilation. Even without the desire to someday accomplish removing all the errors and turning on the setting in the tsconfig, it would be in the best interest of TypeScript developers everywhere to be warned when their code has typing practices which are less-than-safe. My ask is that you add a setting, which can be checked-in via the .vscode/settings.json file, to make strict TS rules optionally visible in the editor. Additionally it would be nice to make these appear as warnings or otherwise be differentiated from errors that would genuinely break the compilation of the code. While there is currently a workaround for this -- compiling with a tsconfig file other than the one that VSCode uses -- it doesn't work with all tooling, makes repos more complicated, and assumes that other tools has flexibility that VSCode itself does not.

[mjbvz]

Moved to TS for more feedback.

For VS Code's strict null adoption, we used a watch build task to show errors from the more strict build in the editor

[RyanCavanaugh]

See #31035

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.