Support overriding type-checking compile flags on a per file basis

[robertknight]

I would like to make use of the --strictNullChecks option in an existing TypeScript codebase that is ~25K LOC in size. Not surprisingly, this throws up a substantial number of errors (~640).

It would be very helpful if it was possible to tackle them gradually and keep the codebase compilable the whole time. The need to be able to tackle these issues gradually is especially true for --strictNullChecks because a reasonable number of the errors that came up are real potential issues that require some thought, rather than problems which can just be fixed in a mechanical fashion.

Ideally what I would like is to be able to suppress checks on a per-file basis, enabling a gradual conversion as follows:

1. Enable --strictNullChecks for the project
2. Attempt to compile and add // @typescript:-strictNullChecks to each file that produces an error
3. Pick the first file with such a directive, remove it and fix any errors.
4. Repeat step 3 for each file with such a directive

Although it is possible to suppress errors with the ! operator, this could end up hiding real bugs and it would be unclear when the operator was used in the process of migration vs. to suppress an error in a case where it isn't possible to statically prove to the compiler that a value is non-null.

[mhegazy]

We did talk about this suggestion before. specifically in the context of declaration files. the conclusion was that it is too subtle of a gesture to change the behavior of the type system.
I will bring it up again for discussion.

Would breaking the project into two pieces (e.g. some modules), and building each separately be an option?

[robertknight]

We did talk about this suggestion before. specifically in the context of declaration files.
the conclusion was that it is too subtle of a gesture to change the behavior of the type system.

Ah, presumably in declaration files that was about changing the behavior of the type system at the point of declaration where it would have non-local effects. Here I'm looking to change the behavior at the point of use. If there was an exported interface declared in a file with a // @typescript:-strictNullChecks directive, I think it would make sense that the directive not affect consumers of the interface in other files.

Would breaking the project into two pieces (e.g. some modules), and building
each separately be an option?

Yes, although that is quite a lot of hassle compared to per-file or directory directives. An alternative that came to mind would be removing the --strictNullChecks option in the normal compile and instead writing a separate tool using the compiler API which compiled the same project using stricter flags and then filtered out the diagnostic messages based on directives in the file or some other config mechanism. Once the entire codebase had been converted over, the option could be turned on in the normal build.

[mhegazy]

This looks like a point-in-time migration request. once all --strictNullChecks issues are handled there will be no need for the per-file flag. on the other hand it is not clear what the flag would mean, suppress errors or change the meaning of T to be T | null | undefined, if it is the first, then these types could leak, and even if you are not getting the errors you are still getting their effect, which is inconsistent at best; if it is the second, the compiler does not have machinery to do this today, so there is a lot of plumping that needs to be done to achieve this, and even with that, the meaning of a type will depend on the header of a file, which is confusing. Moreover any change to the behavior would be a forking of the language. So the complexity introduced in the compiler and to the user we do not believe this is something we should pursue.
Please see #7140 (comment) for more details.

[OliverJAsh]

@robertknight

An alternative that came to mind would be removing the --strictNullChecks option in the normal compile and instead writing a separate tool using the compiler API which compiled the same project using stricter flags and then filtered out the diagnostic messages based on directives in the file or some other config mechanism.

I built something along those lines in #8855 (comment). However, the issue I have now is getting IDEs to provide corresponding feedback to developers. Presumably you would need to wrap the IDE plugin to do some filter, somehow? I opened microsoft/vscode#10337 to try and get more information on how to do this.

[pcj]

Closure compiler has the per-file @Suppress {compilerCheck1|compilerCheck2|...} which is quite useful. Would be good to have this in typescript.

[evmar]

Could you do something like:

1. enable --strictNullChecks locally
2. fix some of the produced errors
3. undo step 1
4. submit the change from number 2
5. go back to step 1 again

In a loop until the whole project passes? Note that it's safe to check in strict null annotations on a project without SNC enabled.