New --strict master option

[ahejlsberg]

This PR introduces a new --strict compiler option that represents the recommended setting of a number of type checking options. Specifically, specifying --strict corresponds to specifying all of the following options (and may in the future include more options):

• --strictNullChecks
• --noImplicitAny
• --noImplicitThis
• --alwaysStrict

When we introduce new type checker features in TypeScript we often put them under a compiler switch and leave them off by default in order 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.

In exact terms, the --strict option sets the default value for the compiler options listed above. This means it is still possible to individually control the options. For example,

--strict --noImplicitThis false

has the effect of turning on all strict options except the --noImplicitThis option. Using this scheme it is possible to express configurations consisting of all strict options except some explicitly listed options. In other words, it is now possible to default to the highest level of type safety but opt out of certain checks.

The PR also modifies the default tsconfig.json generated by tsc --init to include a "strict": true setting in the "compilerOptions" section. Thus, new projects started with tsc --init will by default have the highest level of type safety enabled.

[DanielRosenwasser]

This sort of thing is a bug waiting to happen - it is very likely that next time someone will need to check a flag like noImplicitAny, they will go through compilerOptions first. That said, I'm not sure what else we could do here.

[DanielRosenwasser]

The PR also modifies the default tsconfig.json generated by tsc --init to include a "strict": true setting in the "compilerOptions" section. Thus, new projects started with tsc --init will by default have the highest level of type safety enabled.

Doesn't look like this is an accurate statement.

[ahejlsberg]

Fixed.

[mhegazy]

👍 with chaining the default of --init to true.

[zaggino]

Question, why isn't noImplicitReturns part of the strict mode? or others - noUnusedLocals, noFallthroughCasesInSwitch seem also like something I'd expect in strict mode

[mhegazy]

Question, why isn't noImplicitReturns part of the strict mode? or others - noUnusedLocals, noFallthroughCasesInSwitch seem also like something I'd expect in strict mode

We had a discussion about this, and these checks along with --noUnusedLocals and --noUnusedParameters seemed "style" options and not "type checking" options. that is why the flag description stresses the "type checks" part.

[buu700]

Do you think it's worth putting all the flags that fit in with the group @zaggino mentioned in a separate flag ("strictStyle", or whatever makes sense to call it) or as an optional argument to the strict flag?

The reasoning makes sense to me, but I was surprised to see in today's release notes that those weren't all included; this flag would have been much more useful to me if it did include all that and I could use it as a way to automatically track every strictness-related compiler option going forward.

[mhegazy]

I do ont think so. style checks are by definition subjective. so not every one would agree on the value of enabling one of them. for example the TS code base heavily relies on implicit returns, and fallthroughs, we do not see these as problems.

[styfle]

Is there a Visual Studio compiler flag for --strict?
I found msbuild options but it doesn't mention the --strict option.

[mhegazy]

<TypeScriptStrict>true</TypeScriptStrict>