New --strict master option #14486
New --strict master option #14486
Conversation
| @@ -1564,7 +1566,7 @@ namespace ts { | |||
| error(errorNode, diag, moduleReference, resolvedModule.resolvedFileName); | |||
| return undefined; | |||
| } | |||
| else if (compilerOptions.noImplicitAny && moduleNotFoundError) { | |||
| else if (noImplicitAny && moduleNotFoundError) { | |||
There was a problem hiding this comment.
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.
src/compiler/commandLineParser.ts
Outdated
| @@ -520,7 +525,7 @@ namespace ts { | |||
| export const defaultInitCompilerOptions: CompilerOptions = { | |||
| module: ModuleKind.CommonJS, | |||
| target: ScriptTarget.ES5, | |||
| noImplicitAny: false, | |||
| strict: false, | |||
There was a problem hiding this comment.
The PR also modifies the default
tsconfig.jsongenerated bytsc --initto include a"strict": truesetting in the"compilerOptions"section. Thus, new projects started withtsc --initwill by default have the highest level of type safety enabled.
Doesn't look like this is an accurate statement.
|
Question, why isn't |
We had a discussion about this, and these checks along with |
|
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. |
|
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. |
|
Is there a Visual Studio compiler flag for |
<TypeScriptStrict>true</TypeScriptStrict> |
The `--strict` flag was added in microsoft/TypeScript#14486
This PR introduces a new
--strictcompiler option that represents the recommended setting of a number of type checking options. Specifically, specifying--strictcorresponds to specifying all of the following options (and may in the future include more options):--strictNullChecks--noImplicitAny--noImplicitThis--alwaysStrictWhen 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
--strictoption 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
--strictoption sets the default value for the compiler options listed above. This means it is still possible to individually control the options. For example,has the effect of turning on all strict options except the
--noImplicitThisoption. 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.jsongenerated bytsc --initto include a"strict": truesetting in the"compilerOptions"section. Thus, new projects started withtsc --initwill by default have the highest level of type safety enabled.