fix(@schematics/angular): Turn on strict mode by default in tsconfig

[imcotton]

This should have been turned on to set the best practice from the beginning for the CLI generated project.

[trotyl]

Once microsoft/TypeScript#8476 lands, all Angular project under strict: true will break, isn't it?

[cyrilletuzi]

Nothing will break as Angular support only some ranged versions of TypeScript, as TS doesn't respect semver. For example, Angular 4 is stuck to TS 2.3 because of similar breaking changes.

+1 about this PR. If Angular is in TypeScript, it's for error handling, as it is essential in app development. In non-strict mode, many errors can still happen, so it's quite useless. Now that TS 2.0 has been released a long time ago, and people are now used to strict mode, it's time to strict mode to be the default.

[trotyl]

strict is by design a breaking flag (as a master flag of all dynamic strict*** flags), not related to semantic versioning. From that thread:

Reopening this issue. New plan, look into adding the check under a new flag (on by default under --strict).

So the breaking change is by design due to the new flag (non-breaking for individual flags).

And in the meeting notes, it's explicitly mentioned that Angular won't support this flag:

What about Angular and the like? They wouldn't be able to use this flag.

Angular codebases (especially ones made by angular-cli) and the like should be explicit about their strictnesss options.
Or they could explicitly turn it off when upgrading projects.

Once strict master option is used, then the TypeScript version will be locked forever, or we have to force user to disable that flag manually.

Why doing so if it will clearly cause a breaking change in Angular CLI?

[cyrilletuzi]

If the user sticks to the CLI, there won't be any problem, as the CLI installs only the supported version of TypeScript according to the Angular version installed, and blocks minor updates.

If a user want adventure with newer versions of TS, he/she already have to manually do something by installing a specific TS version, so he/she could turn off strict mode at the same time.

But I agree it may be better if it's only in CLI >= 2.0, or to put only the individual flags supported by Angular.

[trotyl]

It's OK for Angular CLI to throttle the upgrading of TypeScript, but locking it forever is unacceptable. What if we can only use TypeScript 1.5 nowadays in Angular CLI?

This is not a compat issue can be fixed by Angular side (unlike compiler-cli ones).

Angular CLI should make upgrade progress easy, without need to manually changing config files. It's better to use individual flags and (later) warn people who uses strict for the breaking in the incoming versions.

[cyrilletuzi]

Another point : I also like to stay up to date, but for TypeScript, it's not really required with current tooling.

For the TS parsing part, it's not a good idea to update to newer TS versions if Angular doesn't support them. Upgrading TypeScript is really useful for new tools (like new quick fixes). But you don't need to update TS in your app for that : in VS Code for example, by default, the editor uses the last version of TS (not the one of your app). So your app will build, and you'll have the new tools (like quick fixes, etc.) in your editor (even if your app dependencies doesn't really support this newer TS version).

[cyrilletuzi]

Given the direction taken by TypeScript and how VS Code works (using last stable TypeScript version by default), strict by default is not an option anymore : for example, it leads to a lot of errors with new strict property initialization checks in TS 2.7 (see microsoft/TypeScript#20740).

But as another consequence, activating each individual strict option by hand, when Angular supports them, will become more and more painful as more options are added. It may discourage people from using these options, while they should : TypeScript does not activate these options by default to stay transparent with JavaScript, but TypeScript is used to manage errors (ans it's why Angular chose it), and without these options it can't do a job good enough compared to the goal (no error possible in an app, or it crashes).

@filipesilva @hansl @Brocco Would the CLI team accept a PR with individual strict options enabled by default in tsconfig.json ?

[hansl]

strict is not something we want as it's a catch all flag. We will consider the separate flags individually. Closing this.

Please note that we should be compatible with strict by default (and if not it's an issue on our part), we jsut don't want to enforce it to new applications.