Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

strictNullChecks support in v4.0 is broken #15432

Closed
IgorMinar opened this issue Mar 23, 2017 · 11 comments
Closed

strictNullChecks support in v4.0 is broken #15432

IgorMinar opened this issue Mar 23, 2017 · 11 comments

Comments

@IgorMinar
Copy link
Member

@IgorMinar IgorMinar commented Mar 23, 2017

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 #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)
IgorMinar added a commit to IgorMinar/angular that referenced this issue Mar 23, 2017
IgorMinar added a commit to IgorMinar/angular that referenced this issue Mar 23, 2017
IgorMinar added a commit to IgorMinar/angular that referenced this issue Mar 23, 2017
IgorMinar added a commit to IgorMinar/angular that referenced this issue Mar 23, 2017
vicb added a commit that referenced this issue Mar 23, 2017
mhevery added a commit to mhevery/angular that referenced this issue Mar 24, 2017
mhevery added a commit to mhevery/angular that referenced this issue Mar 24, 2017
mhevery added a commit to mhevery/angular that referenced this issue Mar 24, 2017
@IgorMinar IgorMinar added this to the 4.x.x-candidates milestone Mar 24, 2017
mhevery added a commit to mhevery/angular that referenced this issue Mar 24, 2017
@peterkelly
Copy link

@peterkelly peterkelly commented Mar 28, 2017

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.

unlight pushed a commit to unlight/angular-webpack-seed that referenced this issue Apr 9, 2017
@mhevery
Copy link
Member

@mhevery mhevery commented Apr 10, 2017

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
Copy link

@aluanhaddad aluanhaddad commented Apr 10, 2017

@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
Copy link

@peterkelly peterkelly commented Apr 10, 2017

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

@mhevery
Copy link
Member

@mhevery mhevery commented Apr 11, 2017

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

@Delagen
Copy link
Contributor

@Delagen Delagen commented Apr 27, 2017

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

@mhevery
Copy link
Member

@mhevery mhevery commented Apr 27, 2017

Support landed in v4.1

@mhevery mhevery closed this Apr 27, 2017
@CSchulz
Copy link

@CSchulz CSchulz commented Apr 27, 2017

There is still an open bug with forms #16357

@Delagen
Copy link
Contributor

@Delagen Delagen commented Apr 27, 2017

@CSchulz see my comment, not only

@peter
Copy link

@peter peter commented Oct 10, 2017

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
Copy link

@angular-automatic-lock-bot angular-automatic-lock-bot bot commented Sep 12, 2019

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

7 participants
You can’t perform that action at this time.