Review the project setup experience

Today, tsc --init creates a big-ol’ file that is super intimidating. We try to provide comments and blocks of sections to give people a clear separation of config concerns. We also provide a link to https://aka.ms/tsconfig.json.

We also have a belief that most people don’t even use tsc --init.

That said, there are problems, and tsc --init doesn’t make it totally clear what the “best practices” are for starting a project. Things that are missing:

• Project layout guidance (e.g. src, tsconfig naming)
• “well known”/“blessed” flags as opposed to just ONE BIG PAGE of ALL THE FLAGS 😨
• Easy way to find the information regardless of whether a user used tsc --init

In short:

• Docs for tsconfig.json “getting started”
• Link to that in generated tsconfig.json
• Re-evaluate generated tsconfig content.

[renanmontebelo]

I like the fact that tsc --init generates a file with all flags explicitly listed, even if most are commented out. However, I was surprised today when I noticed the commented out flags do not necessarily reflect default values. For instance, the following line is generated

// "sourceMap": true, /* Generates corresponding '.map' file. */

when the actual default value is false. My suggestion is that these values should reflect default values and hence be fully self-documented (no need to visit a webpage to check what the default values are).

[Kinrany]

It would be great to opt into using the latest recommended options as defaults, instead of updating manually (even with tsc --upgrade).

Something like "extends": "recommended".

This is perfectly OK for reproducible builds if the recommended settings only change with compiler versions.

This would also make the generated tsconfig smaller for those who are OK with fixing errors right away or disabling the new options explicitly.