Angular-cli: Add option to enable existing project strict mode
馃殌 Feature request
Command (mark with an x)
- [ ] new
- [ ] build
- [ ] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ x] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc
Description
This doc: https://angular.io/guide/strict-mode shows how to create a project with strict mode, but don't show how to enable strict mode in existing project
Describe the solution you'd like
- Add in the docs more information about changing the strictness mode for existing projects
- Add option to the Angular CLI to enable strict mode in existing projects
saifabusaleh
All 3 comments
Currently ng new --strict is mostly a test for the news features. Eventually we want to "graduate" some of the changes to being included by default and also apply them to existing projects. To do that, we'll need a migration eventually, so we may as well do it sooner than later and make it available as an optional migration for those who choose to opt-in early.
Since these flags increase strictness, they will likely cause compile errors on an existing code base. This is probably expected and manageable for users who want to opt-in. We may want to opt-out any existing offenders from the change where we can. For instance, we can enable the no-any TSLint check, but then add // tslint:disable-next-line:no-any for all existing uses of any. This could also include a TODO to fix it. This would be useful to ignore existing offenses while still tracking them and allowing users to take advantage of the new strictness. Ideally we could do this with all the breaking changes, but that may not be possible, so we'll need to evaluate the practicality of such changes (TypeScript's strict flag in particular would be extremely difficult to do this for).
As a workaround for the time being, the guide does list all the changes comprehensively, though they aren't very well explained about what the exact source code changes are and the complete effects of it. I also gave a talk just the other day which goes through all the changes and in particular explains the side effects change that is probably the most complex and least helpfully documented for this use case. If you want to enable strict mode today, you can basically just add those flags and then fix whatever compile errors occur from them. When we get a future optional migration, this process will be a little bit easier.
dgp1130
on 16 Jul 2020
This is currently 2 issues in one (migration which is assigned to the engineering team, and docs which would be assigned to the docs team). This makes it hard to track these two issues.
@saifabusaleh can you please find/open a separate issue in angular/angular for the docs part of this and link it to this issue?
Splaktar
on 9 Sep 2020
This is currently 2 issues in one (migration which is assigned to the engineering team, and docs which would be assigned to the docs team). This makes it hard to track these two issues.
@saifabusaleh can you please find/open a separate issue in
angular/angularfor the docs part of this and link it to this issue?
Hi @Splaktar
Opened: https://github.com/angular/angular/issues/38771
saifabusaleh
on 9 Sep 2020
Related issues
JanStureNielsen
路
3Comments
rwillmer
路
3Comments
brtnshrdr
路
3Comments
IngvarKofoed
路
3Comments
ericel
路
3Comments
Most helpful comment
Currently
ng new --strictis mostly a test for the news features. Eventually we want to "graduate" some of the changes to being included by default and also apply them to existing projects. To do that, we'll need a migration eventually, so we may as well do it sooner than later and make it available as an optional migration for those who choose to opt-in early.Since these flags increase strictness, they will likely cause compile errors on an existing code base. This is probably expected and manageable for users who want to opt-in. We may want to opt-out any existing offenders from the change where we can. For instance, we can enable the
no-anyTSLint check, but then add// tslint:disable-next-line:no-anyfor all existing uses ofany. This could also include a TODO to fix it. This would be useful to ignore existing offenses while still tracking them and allowing users to take advantage of the new strictness. Ideally we could do this with all the breaking changes, but that may not be possible, so we'll need to evaluate the practicality of such changes (TypeScript'sstrictflag in particular would be extremely difficult to do this for).As a workaround for the time being, the guide does list all the changes comprehensively, though they aren't very well explained about what the exact source code changes are and the complete effects of it. I also gave a talk just the other day which goes through all the changes and in particular explains the side effects change that is probably the most complex and least helpfully documented for this use case. If you want to enable strict mode today, you can basically just add those flags and then fix whatever compile errors occur from them. When we get a future optional migration, this process will be a little bit easier.