Add Advanced Compiler flags in tsconfig.json generated by --init

[borgfriend]

Search Terms

--init
compileroptions
advanced compiler options
resolveJsonModule
tsconfig
default tsconfig

Suggestion

I assumed that the tsconfig.json that is generated by tsc --init provides all available flags with their defaults.

I noticed now that there is a mismatch of the available fields documented here: https://www.typescriptlang.org/docs/handbook/compiler-options.html and the generated tsconfig.json file.

For example the option 'resolveJsonModule' is missing. However there are actually a long list of flags missing. These are all currently categorized as "Advanced".

Option 1: Just add the missing flags to the generated tsconfig.

There is already a category "Experimental" Features. I do not think it would confuse a new TypeScript developer if there is an additional category "Advanced" generated in the 'tsconfig.json' file.

Option 2: have two different init commands

• tsc --init -> creates the current tsconfig.json
• tsc --initAdv -> creates a full tsconfig.json

(Not really a good solution, and makes things more complicated)

Option 3: Add a comment

Add a comment to the currently generated tsconfig.json
something like: "For more Information, and Advanced flags visit: https://www.typescriptlang.org/docs/handbook/compiler-options.html"

Further information

I assumed first it was a bug, that it was forgotten to be added to the default config. However looking at the codebase I discovered:
in the file:
.\src\compiler\commandLineParser.ts

Line 1973: // Exclude all possible Advanced_Options in tsconfig.json which were NOT defined in command line

I could not find any more information why this decision has been made. - But since all information is already available the implementation of this 'feature' should be trivial.

Use Cases

I would like as a user of typescript to have a complete overview of all available compiler flags.
It is akward to have a default template that forgets to mention that even more flags exist.

It would save people time to search for issues that are easily solved by a compile flag.

Examples

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[RyanCavanaugh]

I assumed that the tsconfig.json that is generated by tsc --init provides all available flags with their defaults

This is not correct; the list of flags here is chosen by hand to be those we think are most commonly needed.

[borgfriend]

Why was the flag "Working as intended" added? - Currently there is not a possibility to easily create a tsconfig with all available flags and their default values.

How did you verify which flags are most commonly needed?

For a newcomer to typescript the current tsconfig.json is a long list of compiler flags and a challenge to learn.
For an experienced typescript developer flags are just simply missing.

The word "Advanced" anyway signifies that these are options you probably will not need to touch. I do not fully understand why was a list of flags choosen by hand? What is the benefit? What are the downsides of displaying all flags?

[orta]

I think there's a lot of un-explored space for documenting the tsconfig on the web side, which would make a lot of these problems less of an issue. There were quite a few good ideas for it in #31983 which we've not got to implementing yet.

I think directing people to those docs from the generated tsconfig would make a lot of sense

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[borgfriend]

I created a Pull Request. the tsconfig.json now lists all advanced options and displays a link to the documentation.

I think it is clear that the "handpicked" default values are the ones that you probably should want to change and the rest is disabled.

With this change I think it is a better representation of what compiler flags are currently available.

I guess you could argue that another category would be needed for the Deprecated options, i guess those with the cli-flags could be excluded