[Suggestion] A way to mark `.d.ts` files that they are `strictNullCheck` compliant

[mhevery]

A project often depends on other libraries which come with their own .d.ts files. For example:

Library: lib_a.d.ts

declare function foo(name: string): string;

When my project turns on strictNullChecks it is not clear to me if the lib_a.d.ts can be trusted. Because if it was compiled without strictNullChecks than my project should interpret it as:

Library: lib_a.d.ts

declare function foo(name: string|null|undefined): string|null|undefined;

but if it was compiled with strictNullChecks than the lib_a.d.ts should be trusted as is.

In real life there are often many library dependencies, and I would like to turn on strictNullChecks in my project before I have to wait that all of the third party libraries are ready.

Straw-man syntax would be:

Library: lib_a.d.ts

/// <compiler-options strictNullChecks: true>
declare function foo(name: string): string;

The TS compiler would than adjusted the types on the fly as it reads the libraries because it knows with what options they have been compiled.

[DanielRosenwasser]

We've discussed something like this at some point in the past - the problem is that you now make the task of using anything from that library extremely onerous. Anything returned from the API must now unconditionally be checked or non-null asserted. What's more, inputs to your API are now potentially too lax.

There'd also be the question of what to do with object members - properties would presumably be optional, but would methods?

[mhegazy]

One thing to note is that null / undefined annotations can be added to a library without --strictNullChecks on. for instance the typescript.d.ts has | undefined in multiple places, even though we do not compile with --strictNullChecks just to enable users who use --strictNullChecks.

Our analysis of libraries also showed that most APIs do not change, and that the library definition with no null/undefined annotations is likely usable with --strictNullChecks.

Our recommendation is to flip --strictNullChecks on your code base, using the existing declaration files for your dependencies; for blocking issues in your dependencies push fixes to their .d.ts even though they do not --strictNullChecks.

We believe this is a point in time, and moving forward new libraries will be null-aware. We have enforces this on DT new definitions for instance.

[RyanCavanaugh]

We could really use this to make #9041 ergonomic

[RyanCavanaugh]

Without a clear distinction between input and output positions, this is kind of useless - from a read position you want to keep null and undefined out of the type (to avoid having to write foo!.bar!.baz! everywhere), but write positions sort of want null/undefined added (even though presuming that foo(null) is acceptable in the absence of evidence to the contrary is really suspect). So the status quo seems like the best bet.