Definitelytyped: Make compatable all definitions with new compiler argument --strictNullChecks

[bashor]

More inforemation about strictNullChecks here: https://github.com/Microsoft/TypeScript/pull/7140

[vvakame]

:+1: We'll start it when typescript 2.0 shipped.

[horiuchi]

That's good feature! :+1:

[alexeagle]

Could we start landing these changes on the types-2.0 branch (is that meant for TS 2.0?)
We have started updating Google code to --strictNullChecks and have local modifications to d.ts files that we could upstream, if there was a place for them.

[cspotcode]

Ditto what @alexeagle said; I would love to contribute updates to the declarations that I use so that they'll be ready to go when TS2.0 ships. Should I just keep them in my fork? Is there a branch I can submit PRs against?

[andy-ms]

Hi @cspotcode, that branch is the types-2.0 branch. Every package there _should_ (many don't, but we're accepting PRs) have a tsconfig.json, and it would be great to turn on "strictNullChecks": true in as many of those as possible. (To create a tsconfig.json, just copy from a package nearby and change the files; they should all be identical except for files, strictNullChecks, and some add jsx.) Currently it's enabled for a grand total of 7, so we've got work to do.

The types-2.0 branch also gets published to the @types scope on NPM. We also manually merge in changes from master to types-2.0 once in a while.

[alitaheri]

@andy-ms Since typescript 2 has been published. Should we start enforcing strictNullChecks? My application fails sometimes because I have it enabled. but some definitions aren't compatible.

[andy-ms]

It's up to you whether you want strictNullChecks in your own code, but a type definition with | null and | undefined used appropriately is strictly better than one without them — these will just be ignored if you're not using strictNullChecks.

[alitaheri]

The problem is: When you use generics constraints, the strictNullChecks won't allow null or undefined to be assigned to types not including the corresponding null or undefined type:

interface Foo {
  a: number;
}

interface Bar<T extends Foo> {
  a(): T;
}

interface Baz<T extends Foo | null> {
  a(): T;
}

// strictNullChecks=true => error: [ts] Type 'null' does not satisfy the constraint 'Foo'.
// strictNullChecks=false => no error.
type Bad = Bar<null>; 
type Good = Baz<null>;

This gives me compilation errors simply because I have installed a library ( i.e. @types/d3-selection ). If the rule is enforced for all libraries like noImplicitAny then such edge cases won't occur. You can open d3-selection or d3-focus, enable strictNullChecks and see the compiler errors in the definition files.

[andy-ms]

Then d3-selection and d3-focus should be upgraded. All libraries should have strictNullChecks, especially those that are already explicitly using the null type.

[Ledragon]

You can follow the progress of the d3-related modules in issue #23611