Create unified tsconfig preset

[remcohaszing]

Across unified projects a similar tsconfig.json is used with very similar settings.

It might be nice to have a preset to extend from. This preset can also define some options that are often forgotten.

{
  // Maybe add "build" and "dist" too?
  "exclude": ["coverage", "node_modules"],
  "compilerOptions": {
    "checkJs": true,
    "declaration": true,
    "emitDeclarationOnly": true,
    // Missing in many projects (recommended by TypeScript docs)
    "exactOptionalPropertyTypes": true,
    // Missing in many projects (recommended by TypeScript docs)
    "forceConsistentCasingInFileNames": true,
    "lib": ["es2020"],
    "module": "node16",
    // Default is platform specific, which is weird to me.
    "newLine": "lf",
    "skipLibCheck": true,
    "strict": true,
    "target": "es2020"
  }
}

Some options are deliberately omitted.

• "moduleResolution": "node16" is implied if "module": "node16"
• "allowSyntheticDefaultImports": true is implied if "module": "node16"
• "allowJs": true is implied if "checkJs": true
• "skipLibCheck": true although recommended by the TypeScript handbook, I think it’s a bad idea for libraries, because it hides type errors that cause type errors for dependants, meaning they are also forced to use skipLibCheck.

Now unified projects just have to use the following tsconfig.json:

{
  "extends": "unified-tsconfig"
}

Options can still be overridden.

[wooorm]

Yeah, I’m in favor

• I, like you, prefer lowercase
• sure, let’s try build and dist too, we can see when it gets annoying
• Might be good to document which ones are deliberately not needed
• We can try without skipLibCheck, but I dunno... I don’t get why TS delves that deep? I haven’t found a good reason for not having it. Seems like those dependants should also just do that 🤷‍♂️

[ChristianMurphy]

I'm also in favor

We can try without skipLibCheck, but I dunno... I don’t get why TS delves that deep? I haven’t found a good reason for not having it. Seems like those dependents should also just do that 🤷‍♂️

I get this view, though tend to prefer keep lib checks enabled.
It can be a good warning sign if/when there are compatibility issues deeper in the dependency tree.
It can be unnecessarily noisy at times, those cases seems to be roughly the same projects with deep dependency trees that would run into issues with npm audit (context)

[remcohaszing]

I myself am not entirely sure about this anymore. (This doesn’t mean I‘m against it now.) This is partially because some options have gotten simpler with "module": "node16".

I have some new insights:

• forceConsistentCasingInFileNames will be enabled by default in TypeScript 5.
• newLine will default to lf in TypeScript 5, and current behaviour will be removed.
• lib matches ${target}.full by default. The ${version}.full libs include ${version}, lib, dom, worker, and web worker types. If lib is set to ${target}, this basically means explicitly disabling browser types. For example, see es2022.full.
• strict is merely an option that enables some other options. What options it enabled, may change in minor versions. I generally like strict, but for a preset it’s arguably better to cherry-pick strict options manually.
• Setting module to node16, sets moduleResolution to node16 and enables esModuleInterop. In the rare case we still use commonjs, we want to set moduleResolution to node16, but not anything else provided by that module option. So for a preset it would be good to set moduleResolution to node16 additionally. I.e. for @mdx-js/loader we should use this:

  {
    "extends": "unified-tsconfig",
    "compilerOptions": {
      "module": "commonjs"
    }
  }

• Likewise, checkJs implies allowJs. However, if for some particular reason one projects disables checkJs, it would still be nice to use a @ts-check comment to enable type checking for a specific file. So it makes sense to enable allowJs in a preset.
• skipLibCheck ensures the types of a library work with those of its dependants. I’d argue this is useful to know when developing libraries. For end user applications I think this is less useful, which I guess is the reason the handbook recommends to disable it.