Bayan Bennett

πŸ‘ Stop πŸ‘ Messing πŸ‘ with πŸ‘ TSConfig

I once spent half a day debugging issues in a codebase only to discover that the cause was a horribly butchered TSConfig file. It looked like the file was pieced together with config options from random tutorials. As if, after the creation of the tsconfig.json file, tsc was run and someone exclaimed "it works!". Hands were clapped, and then project development just moved on without a second thought.

After finally figuring out the cause of all the error messages, I thought, "ESLint has eslint:recommended and @typescript-eslint/recommended, there must be a recommended tsconfig out there." Lo and behold such a library exists to save us from the perdition of configuration, and it's called @tsconfig/bases.

Created on 13 May 2020, @tsconfig/bases provides base tsconfig.json files for new and old projects alike. Their purpose is to provide developers with a good base configuration. Most projects don't need the full configurability that TSConfig files offer.

Is this necessary to use one of the @tsconfig/bases? No. Will it increase consistency across projects? Yes.

Installation

As of writing this post, 8 templates are provided:

  • deno
  • docusaurus v2
  • node10
  • node12
  • node14
  • react-native
  • recommended
  • svelte

Each can be installed via npm/yarn, where $TEMPLATE is replaced by one of the names listed above.

npm install --save-dev @tsconfig/$TEMPLATE
yarn add --dev @tsconfig/$TEMPLATE

For example: npm install --save-dev @tsconfig/recommended

My Most Common TSConfig

{
  "extends": "@tsconfig/recommended/tsconfig.json",
  "compilerOptions": {
    "jsx": "react",
    "resolveJsonModule": true
  },
  "include": [
    "src/**/*"
  ]
}

…That's it…

I can set it and forget it. When I revisit a tsconfig.json file in a different project, I can quickly see what's different. Usually, the difference is just a few extra keys in compilerOptions. Quick and painless.

Here's what @tsconfig/recommended/tsconfig.json looks like:

{
  "compilerOptions": {
    "target": "ES2015",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "Recommended"
}

Any of the config options in your file will be preferred to what's in @tsconfig/recommended/tsconfig.json. So if any of the recommended options are causing issues (most likely strict), you can override them in your config.

A strict Reminder

strict turns on all of TypeScript's strict settings:

  • alwaysStrict
  • noImplicitAny
  • noImplicitThis
  • strictBindCallApply
  • strictFunctionTypes
  • strictNullChecks
  • strictPropertyInitialization

TL;DR

Using a config from @tsconfig/bases helps to clean up tsconfig.json files, making them shorter, easier to debug, and elevating consistency across projects.

Β© 2021 Bayan Bennett