@21kb/tsconfig NPM

Opinionated, yet fully extensible TypeScript config

Install

npm install --save-dev @21kb/tsconfig

Usage

Extending the config

{
  "extends": "@21kb/tsconfig/tsconfig.json",
  "compilerOptions": {
    "baseUrl": ".",
    "outDir": "dist"
  }
}

Overriding existing options

{
  "extends": "@21kb/tsconfig/tsconfig.json",
  "compilerOptions": {
    "outDir": "dist,
    // Emit `.jsx` files with the JSX unchanged
+    "jsx": "preserve",
  }
}

Setting the target to ESNext includes lib from ESNext. These APIs are considered unstable, and change as the JavaScript specification evolves. If you prefer to use another version, check the relevant ECMAScript version you wish to upgrade to, and set that as the target:

{
  "extends": "@21kb/tsconfig/tsconfig.json",
  "compilerOptions": {
    "outDir": "dist",
    "target": "ES2021"
  }
}

You might also want to look into tweaking lib to match target, or remove lib altogether, and let TypeScript handle it.

Why?

Why are type-checking options like `allowUnreachableCode` (`no-unreachable`), `noImplicitReturns` (`consistent-return`), `noUnusedLocals` (no-unused-labels), and `noUnusedParameters` (`no-unused-vars`) not enabled?

Most (if not all) TypeScript type-checking features are already present in ESLint. Use ESLint to catch these errors (warnings) instead.

Why is `jsx` set?

While the argument could be made that not every TypeScript project is a React project, every React project should be a TypeScript project*. Setting this option only affects the output of JS in .jsx files. If you are not using React in your project, then this setting should not affect you at all.

* This is an opinion, not a fact. In my experience, TypeScript helps greatly in small to mid-size projects being worked on by an individual engineer, or a small team of engineers. On the other hand, many argue that TypeScipt has deminishing returns