You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Enable strictNullChecks mode for aio codebase #20646
Having this mode on would help us catch more bugs using the typechecker and would also help us better understand the TS upgrade pain for users with this mode on (currently we have this mode on in g3 and angular framework code base, but we don't have any of our non-g3 apps using that mode).
We can always explcitly opt-out of specific options. That's better than opt into imo.
Also, I am not sure why this is incompatible with Angular (why can't you initialize input properties anyway)?
Also, we just landed support for TS 2.5. Let's worry about 2.7 when we get there 😃
I am not sure why this is incompatible with Angular
In Angular we always initialize input properties AFTERconstructor and before ngOnInit, so that's an error in TypeScript as it cannot detect the initialization (and if the properties are not nullable).
We can always explcitly opt-out of specific options.
That's a good idea, but Angular CLI seems unable to auto-update tsconfig, so may not apply there (sorry for off-topic, still fine for angular.io). 😄
You can always explicit | null = null 😃
Just to be clear, we are talking about just the angular.io app. But even if we end up turning --strictPropertyInitialization off, it is better to be "strict by default" 😃
I feel like enabling the --strict flag, would provide for the safest / best use of typescript protection going forward. This would definitely be an undertaking for all of Angular but maybe shooting for this in release 6.0 could be a possibility? I hope @IgorMinar and the Angular team would at least take this into consideration.
New checks added to TypeScript are often off by default to avoid breaking existing projects. While avoiding breakage is a good thing, this strategy has the drawback of making it increasingly complex to choose the highest level of type safety, and doing so requires explicit opt-in action on every TypeScript release. With the --strict option it becomes possible to choose maximum type safety with the understanding that additional errors might be reported by newer versions of the compiler as improved type checking features are added.
Activity
gkalpak commentedon Nov 28, 2017
Should we enable all
--strictchecks? Please? 😛From the TS handbook:
trotyl commentedon Nov 28, 2017
@gkalpak the
--strictmaster option in tsconfig will break Angular in TypeScript 2.7 due to the new--strictPropertyInitializationoption. It was mentioned in microsoft/TypeScript#15360 and microsoft/TypeScript#20117.gkalpak commentedon Nov 28, 2017
Thx for the heads-up 👍
We can always explcitly opt-out of specific options. That's better than opt into imo.
Also, I am not sure why this is incompatible with Angular (why can't you initialize input properties anyway)?
Also, we just landed support for TS 2.5. Let's worry about 2.7 when we get there 😃
trotyl commentedon Nov 28, 2017
In Angular we always initialize input properties AFTER
constructorand beforengOnInit, so that's an error in TypeScript as it cannot detect the initialization (and if the properties are not nullable).That's a good idea, but Angular CLI seems unable to auto-update
tsconfig, so may not apply there (sorry for off-topic, still fine for angular.io). 😄gkalpak commentedon Nov 28, 2017
I mean there is nothing stopping you from initializing input properties in the component:
trotyl commentedon Nov 28, 2017
That's true, but I guess most input properties may not have a default value? 😄
gkalpak commentedon Nov 28, 2017
You can always explicit
| null = null😃Just to be clear, we are talking about just the
angular.ioapp. But even if we end up turning--strictPropertyInitializationoff, it is better to be "strict by default" 😃danwulff commentedon Nov 28, 2017
I feel like enabling the
--strictflag, would provide for the safest / best use of typescript protection going forward. This would definitely be an undertaking for all of Angular but maybe shooting for this in release 6.0 could be a possibility? I hope @IgorMinar and the Angular team would at least take this into consideration.From the typescript 2.3 release notes: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-3.html#new---strict-master-option
style(aio): enforce strict TypeScript checks (#21342)
angular-automatic-lock-bot commentedon Sep 13, 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.