My TypeScript recommendations and cheatsheet
A set of recommended defaults and configuration options cheatsheet for good TypeScript configuration defaults.
TypeScript official config reference is overwhelming to say the least. It includes many flags that were introduced and deprecated over the years. Standards and practices have evolved and it’s hard to keep up with the pace of changes.
The Fast Track if you’re in a hurry
I wrote a command line interface that helps you setup TypeScript quickly with a few interactive prompts:
npx simplefrontend setup typescriptThis CLI can do a bit more, you can read about it here.
Server apps, librairies and local script
Getting started with good TypeScript configuration defaults
I will provide you with configurations that enable very simple and fast development and production setups. These recommendations are build on top of a good set of good and strict standards.
For server applications, librairies and local scripts, I’ve been using tsconfig/bases from Orta for a while now and that helps both abstract some of the baseline recommendations and keep up with the ecosystem changes especially to know which lib to target for which node versions.
So I’d recommended the following:
- Install TypeScript config dependencies:
- @types/node to get type definitions for Node.JS .
- @tsconfig/node-lts to target the latest Node.JS long-term support version, you can also target different versions if you need.
- @tsconfig/strictest to start with the strictest baseline.
- Update your
package.jsonfile to make use of the ES module syntax with the following:
"type": "module"- a) For a server configuration or local scripts, use the following
tsconfig.json
{ "extends": [ "@tsconfig/node-lts/tsconfig.json", "@tsconfig/strictest/tsconfig.json" ], "compilerOptions": { "rootDir": "./src", "outDir": "./dist",
"types": ["node"],
"moduleDetection": "force", "verbatimModuleSyntax": true, "rewriteRelativeImportExtensions": true, "erasableSyntaxOnly": true,
"sourceMap": true,
"forceConsistentCasingInFileNames": true, "noUncheckedSideEffectImports": true, }, "include": ["./src"],}- b) For a library, use the following
tsconfig.json
{ "extends": [ "@tsconfig/node-lts/tsconfig.json", "@tsconfig/strictest/tsconfig.json" ], "compilerOptions": { "rootDir": "./src", "outDir": "./dist",
"moduleDetection": "force", "verbatimModuleSyntax": true, "rewriteRelativeImportExtensions": true, "erasableSyntaxOnly": true,
"sourceMap": true, "declaration": true, "declarationMap": true,
"forceConsistentCasingInFileNames": true, "noUncheckedSideEffectImports": true, }, "include": ["./src"],}These configurations allow a simple and fast development and production setups thanks to Node.JS type erasure with the following package.json scripts:
"scripts": { "dev": "node --watch src/server.ts", "build": "tsc", "start": "node dist/server.js" }Here are some explanations and reasoning for my recommendations:
includeto make sure you’re not including uneeded files which would slow down the compilation.moduleDetectionset to “force” to make TypeScript consider all files as modules which help catch more errors.verbatimModuleSyntaxto help provide stronger guarantees on imports and prevent potential erroneous side effects on type imports.rewriteRelativeImportExtensionsis a bit more opinionated: it makes things less indirect for me and simplifies the pure Node.JS development setup.erasableSyntaxOnlyis also quite opinionated: it forces you to write TypeScript code which is easy to erase to run valid JavaScript. You then cannot use new constructs such asenumsbut I believe it’s a worthy trade-off as those are features I would not recommend to use anyway.forceConsistentCasingInFileNamesandnoUncheckedSideEffectImportsare stricter best practices.
Client apps
Given the variety and complexity of client side setups, I recommend to follow the configurations starters for Vite starters which you can find here. They provide the latest best-in class TypeScript configuration recommendations you can extend to make stricter with some of the options I recommended above.