Turn on --strictNullChecks in codebase

[DanielRosenwasser]

This is important for consumers of our API and for testing the feature in general

[ajpalkovic]

Greetings. OOC, has any thought been given on how best to convert a large codebase to use strictNullChecks? It seems like an awesome feature and I'd love to turn it on. But my team has ~400k LOC in typescript. Turning this on all at once thus results in about 33 thousand lines of error output from 5,170 distinct errors :( That is certainly not your fault but it does make it really hard to use the new feature on a large existing codebase. Is there a magic way to turn this on for only some files at once so a migration can be done more incrementally? es5 seems to have foreseen this problem so that added 'use strict' so that you can opt-in a file to the new safety checks but you don't have to convert your entire code base to the new safety checks all at once and legacy code will continue to work as is. But yea, any thoughts on that? cc @bobthecow

[mhegazy]

We have the same issues with the TypeScript code base moving it strict null checks. The approach we have taken is to start with components/modules that are lowest in the dependency graph, turn on --strictNullChecks and look at the errors for this specific component/module, fix them, but do not turn on the flag for the whole build. iterate until the whole code base is in a good shape, then switch it on for all components/modules.

[realyze]

Hmmm, would there be any big implementation problems with per-file flag that would turn strict checking on just for that file? IMHO it would definitely help with adoption of this great feature.

[RyanCavanaugh]

It's extremely unclear what per-file typechecking flags would even mean. Types can span multiple files; is it that the relation changes within a specific file, or that the types themselves change depending on where they are declared? Both have serious problems.

[ajpalkovic]

My 2c: The goal is to be able to incrementally convert a large code base to a much stricter compilation option. The per-file flag is just one way of doing that, we just need some tool to help us make that happen. My hope would be that there is a reasonable way to express "only produce strictNullChecks compiler errors for files with this magic flag at the top of the file"?

[realyze]

@ajpalkovic Right, that's actually what I meant (strict error reporting for a subset of files only), I just didn't explain myself well. Thanks!

@RyanCavanaugh Gut feeling is that's a pretty low-hanging fruit, amiright? And I believe it would help with adoption a lot. Right now - regardless of the absolute awesomeness of this feature - it's extremely hard to turn it on with existing codebases.

[RyanCavanaugh]

Gut feeling is that's a pretty low-hanging fruit, amiright?

It's the hardest-to-reach fruit. It's not clear where in the tree this fruit even is, other than that it's really high up. Consider something like this:

// a.ts
declare function fn(x: string): boolean;
declare function fn(x: number | undefined): string;

// b.ts
let x = fn(undefined);

// c.ts
// strictNullChecks: off
let z: string = x;

To really emulate strictNullChecks being off in c.ts, you'd have to completely redo the compilation of the entire program. It's not even clear what it would mean to have strictNullChecks off in b.ts? Would a different overload in a.ts be selected?

Honestly the only remotely correct way to do this would be to:

1. Compile everything with strictNullChecks on
2. Compile everything with strictNullChecks off
3. Filter the resulting errors based on whether or not they occurred in both passes

But even at this point it's not guaranteed that compiling each file individually with strictNullChecks on and getting 0 errors means that the entire program is error-free with strictNullChecks on globally.

[realyze]

@RyanCavanaugh Is it possible that you're perhaps overthinking this somewhat? Or maybe I'm underthinking it, I'm not sure. :-) But this would be only about hiding strict-null errors from the output for the other files than the ones with a flag (say /** ts: strict-null **/ or something similar).

See I agree only checking a single file would be hard (or even impossible to do in a meaningful way) - but we're talking about managing the output here, not about changing the semantics.

Does that makes sense?

[RyanCavanaugh]

There's no such thing as a "strict null error". There's no place where we say if (badNullAssignment) { error (...). The strict null check flag simply changes which values are in the domain of certain types, which causes errors to occur much later in the process. It's like changing + to mean *, doing a bunch of math under this change, and then trying to work out what the answer would have been had you not made that change without knowing what the process that got you to that result was.