tsc --init update 2024

[RyanCavanaugh]

Acknowledgement

• I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

Comment

Following up from #58417

Note: This is only for argumentless tsc --init. We know that it's physically possible to write text after --init and that text could do something, but that's a separate issue. Since tsc --init should do something, this issue is only about what that something is.

General consensus from the design meeting + external discussion:

• No one likes the huge wall of text
• Not many people like the commented-out options, and certainly not the "terrible idea" commented-out options
• "module": "commonjs" is a hard no

Other live issues:

• Should we set '"types": []' for 'tsc init'? #39354 - set types to [] - yes
• Increase default tsc --init target over time #49206, Make tsc --init generate default target to ES6 or higher #39308 - increase default target - also yes
• Enable "useDefineForClassFields" in tsc --init #39311 - set udfcf - I would argue moot by now since we should set the target high enough that this doesn't matter
• Consult package.json contents when creating tsconfig.json under tsc --init to determine better defaults #51207 - consult package.json - it's not obvious that your package.json is configured yet at the time you run tsc --init, this seems marginal

Other things we didn't get to:

• rootDir, outDir: These are generally a good idea; no one likes the default side-by-side JS emit buuut there aren't strictly universal conventions here

Proposed new output:

{
    // For more info, see https://aka.ms/tsconfig
    // Or use the tsc-init wizard: https://aka.ms/tsc-init
    "compilerOptions": {
        "target": "es2022",
        "module": "nodenext",
        "rootDir": "./src",
        "outDir": "./dist",

        // For nodejs, add "node" to this array,
        // and remove "dom" from "lib"
        "types": [],
        "lib": ["dom", "es2022"],

        // Other outputs
        "sourceMap": true,
        // "declaration: true,

        // Typechecking options
        "noUncheckedIndexedAccess": true,
        "exactOptionalPropertyTypes": true,

        // Style options
        // "noImplicitReturns": true,
        // "noImplicitOverride": true,
        // "noUnusedLocals": true,
        // "noUnusedParameters": true,
        // "noFallthroughCasesInSwitch": true,
        // "noPropertyAccessFromIndexSignature": true,

        // We recommend all of these options
        "verbatimModuleSyntax": true,
        "isolatedModules": true,
        "moduleDetection": "force",
        "skipLibCheck": true,
        "strict": true
    }
}

I tried to order this from "most likely to edit" to "least likely to edit"

[andrewbranch]

Module options look good to me for Node.js / library authoring. I assume you’ve intentionally left in some redundancies so that good option A stays set if someone changes/removes option B that’s currently making A redundant. For good measure, a list of those:

• --module nodenext implies --target esnext; you have it set to es2022 (seems good to keep it set as is)
• --module nodenext implies --moduleDetection force
• --verbatimModuleSyntax implies --isolatedModules (people are more likely to turn off the former)

The one that’s missing from this good-but-redundant category is --module nodenext implies --esModuleInterop, which is a good idea to keep on, but the thing people are likely to switch to is --moduleResolution bundler, which implies --allowSyntheticDefaultImports, which is close enough. So not critical to add, I think.

TLDR looks good 👍

[DanielRosenwasser]

Though originally I was thinking more about include over rootDir, it makes sense given the guardrails rootDir provides if you screw something up? And that's important given people try to do custom exclude/include rules that are often unnecessary.

So I'm generally in favor around outDir and rootDir. The thing I am curious about is if we can detect sensible conventions such as folder name and existence of a package.json. This includes stuff like src as a well-known input directory, and special casing depending on if you're running from inside src.

[RyanCavanaugh]

👍 / 👎 ?

        // Other outputs
        // "declaration": true,
        // "sourceMap": true,

[andrewbranch]

Pretty much everybody is going to debug at some point, and it’s going to be bad until they realize they need to enable sourceMap

[fatcerberus]

The only thing that sucks about having options commented out is you can't hover on them to see the description of what they do, which doesn't help when you don't know what something does and want to know if you should enable it. Unfortunately most options don't have an explicit setting that means "use the default behavior, whatever it happens to be today", so no easy solutions to be found here.

[Conaclos]

I could also suggest turning off allowUnreachableCode. It greatly help in some circumstance.