strictNullChecks support in v4.0 is broken

[IgorMinar]

I'm submitting a ... (check one with "x")

[x] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior
Originally we implemented strictNullChecks support by hand-modifying the public api surface and testing apps against that with strictNullChecks tsc option on. We though we got a good coverage and fixed all the issues, but during the RC we started noticing that we missed quite a few places.

Eventually @mhevery went off to implement this properly by actually making the Angular codebase compile with strictNullChecks on without hand-tweaking the API. This work (#15405) surfaced a lot more issues with our public api surface that affects apps that do turn on strictNullChecks.

To make matters worse, we realized that if we were to allow apps to turn on strictNullChecks with these bugs in our public api surface, we wouldn't be able to fix the issues without breaking the apps that do turn on strictNullChecks.

Expected behavior
Correct strictNullChecks support.

Proposed plan

• Prevent applications from turning on strictNullChecks for now via a bogus symbol in our api that fails the strict null check
• Release 4.0 without the strictNullChecks support
• Merge @mhevery fix: Update types for TypeScript nullability support #15405 and any other follow up PRs related to this
• Release the strictNullChecks support in 4.1 (due in April, approximately one month from now)

[peterkelly]

Why are you actively introducing code to prevent strictNullChecks, when it would otherwise work properly for at least a subset of cases?

In a project I am working on, we have successfully been using strictNullChecks since 1.6. During our migration to Angular 2, we had to have our build process apply some patches we created to a small number of definition files in the API so that our code would continue to build, but other than that it has been working fine (including in combination with Ionic 2.0).

I can understand the desire to ensure that the public API definition files properly reflect whether or not certain functions can accept or return values that are null or undefined, and that introducing null or undefined to a type constitutes a breaking API change. However, given that there are already existing projects that are using Angular with strictNullChecks (e.g. because they had a large existing codebase which already worked with it, and added Angular 2+ as a dependency), these changes are already breaking anyway.

Perhaps it might be worthwhile distributing strictNullCheck-compatible definition files that can be used as an option instead? I'm tempted to do so as part of a separate npm package, but if this is likely to be resolved shortly then it's probably better for me to wait it out.

[mhevery]

Because the type information is broken, and once we fix it we would break a lot of people, hence we could not roll it out in v4.1, but have to wait until v5. So by preventing people, we are saying this never worked, and it becomes a feature of v4.1.

If you really insist on doing strictNullChecks in your code knowing that you will be broken in v4.1 than you can put "skipLibCheck": true, in your tsconfig.json which would allow you to turn on "strictNullChecks": true, without braking your build.

[aluanhaddad]

@mhevery As you know, this disables checking of all .d.ts files. This includes hand authored application level declarations. Although these files can generally be simply changed to .ts, this is not always the case.

Regardless, disabling checking of all libraries is not an acceptable workaround.

It is toxic.

[peterkelly]

I think I'm just going to stick to Angular 2

[mhevery]

BTW, enabling string null checks is on top of my priority list, so this should be fixed soon.

[Delagen]

As for me compiler error only on forms and http components and 1 for core

[mhevery]

Support landed in v4.1

[CSchulz]

There is still an open bug with forms #16357

[Delagen]

@CSchulz see my comment, not only

[peter]

As of 10:th of October 2017 I cannot compile the latest released version of Angular (4.4.4) with latest TypeScript (2.5.3) and scrictNullChecks. Failures:

Error at node_modules/@angular/core/src/change_detection/differs/default_iterable_differ.d.ts:2:22: Class 'DefaultIterableDifferFactory' incorrectly implements interface 'IterableDifferFactory'.
Types of property 'create' are incompatible.
Type '(trackByFn?: TrackByFunction | undefined) => DefaultIterableDiffer' is not assignable to type '{ (trackByFn?: TrackByFunction | undefined): IterableDiffer; (_cdr?: ChangeDetectorRe...'.

Error at node_modules/@angular/core/src/change_detection/differs/default_iterable_differ.d.ts:10:22: Class 'DefaultIterableDiffer' incorrectly implements interface 'IterableChanges'.
Types of property 'forEachOperation' are incompatible.
Type '(fn: (item: IterableChangeRecord, previousIndex: number | null, currentIndex: number | null) =...' is not assignable to type '(fn: (record: Iterabl

Error at node_modules/@angular/core/src/change_detection/differs/default_iterable_differ.d.ts:10:22: Class 'DefaultIterableDiffer' incorrectly implements interface 'IterableDiffer'.
Types of property 'diff' are incompatible.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}