tsc --init issues

[aaronbeall]

TypeScript Version: 2.6.2

Code

tsc --init

Expected behavior:

Includes all compiler options and valid values.

Actual behavior:

• Missing forceConsistentCasingInFileNames, skipLibCheck, pretty, allowUnusedLabels, allowUnreachableCode, suppressImplicitAnyIndexErrors options
• Comment for lib is /* Specify library files to be included in the compilation: */ (nothing after the colon)

[aaronbeall]

Missing forceConsistentCasingInFileNames, skipLibCheck, pretty, allowUnusedLabels, allowUnreachableCode, suppressImplicitAnyIndexErrors options

Hm, so those above are the options I'm personally familiar with, but if I compare the init generated tsconfig with the json schema there are actually 29 compiler options not included:

["charset", "declarationDir", "diagnostics", "emitBOM", "reactNamespace", 
"listFiles", "newLine", "noEmitHelpers", "noEmitOnError", "noLib", "noResolve", 
"noStrictGenericChecks", "skipDefaultLibCheck", "skipLibCheck", "preserveConstEnums",
"pretty", "suppressExcessPropertyErrors", "suppressImplicitAnyIndexErrors", 
"stripInternal", "watch", "allowUnusedLabels", "allowUnreachableCode", 
"forceConsistentCasingInFileNames", "plugins", "traceResolution",
"noImplicitUseStrict", "listEmittedFiles", "maxNodeModuleJsDepth", "jsxFactory"]

I guess there's an argument that some of those options wouldn't be very helpful to include in the generated config at all (like encoding options) but there's certainly some that I would expect to be there.

[RyanCavanaugh]

The list of options provided by tsc --init is intended to be somewhat curated; we don't want people randomly turning on e.g. suppressImplicitAnyIndexErrors unless they have really thought about it.

[mhegazy]

So the list as it shows now is limited to what we have deemed worthy of inclusion. i personally do not see forceConsistentCasingInFileNames, skipLibCheck, allowUnusedLabels, allowUnreachableCode, suppressImplicitAnyIndexErrors as worthy. pretty might be worth it though..

so what is this bug tracking? including them all?(do not think this is a good idea) or just specific ones? (if so which)?

[aaronbeall]

so what is this bug tracking?

There's also the comment for lib that currently says /* Specify library files to be included in the compilation: */ -- I would think something should come after the colon, even if it isn't an exhaustive list?

Also, maybe it's just me but I was surprised there are so many options not listed in the generated config, I kind of thought it was all the options, though I can see why it isn't and shouldn't be -- would it be excessive to include a comment in there that there are additional compiler options?

[mhegazy]

would it be excessive to include a comment in there that there are additional compiler options?

well.. part of it is that some of these options are not really used. we can not remove them for back compat purposes.. for instance allowUnreachableCode. our data shows this setting used in less than 0.01% of the total sessions.. so the idea is why let everyone figure out their way through these options, if they are likely not going to use them.

to see all options supported by the compiler, try tsc --help --all

[mhegazy]

There's also the comment for lib that currently says /* Specify library files to be included in the compilation: */ -- I would think something should come after the colon, even if it isn't an exhaustive list?

feel free to send a PR to remove the colon from the message

[nieltg]

feel free to send a PR to remove the colon from the message

@mhegazy
Hi! I'm going to try fixing that. Pull request #21174.