Setting up tsconfig.json
Using the TypeScript compiler (tsc
) is the most simple way to get started. Probably simpler than any Babel-related setup you've ever used. tsc
can be added to your PATH by globally installing TypeScript (npm i -g typescript
).
... generates a main.js
file in the same folder with default compiler settings. -w
toggles the watch mode.
A simple project
Below we go through setting tsconfig.json for a simple project compiled using
tsc
. This is mostly commonly used in backend projects. If you are using a predefined build pack like "Create React App", "Next.js" or "Nest.js", this already comes set up. Also, those build configurations use javascript bundlers like "Webpack" or "SWC" instead of rawtsc
.
For a project, it is recommended that you install TypeScript locally so that your project is tied to a specific TS version. In VSCode, tsc
can be invoked through F1 > Run Build Task. You should also include a link for it in the package.json scripts
.
tsc
looks for a tsconfig.json
file in the same folder. When a tsconfig
is around, you can just call tsc
without arguments. The tsconfig
accepts an overwhelming set of compiler options -- since it mixes compiling and type checking options. Below I'll go through a set of recommended settings.
include
filters which files to compile. This can be a folder or an entry point (every file referenced by that entry point will also be compiled);
I will usually split input and output files in different folders:
By default
tsc
outputs to the same folder the source files are. Use"outDir": "built"
to fix that;
Sourcemaps allow you to debug directly in the source
.ts
files.
Those 3 are output settings:
target
dictates how old is the runtime you want to support;module
allows for import/export syntax conversion; You'd usually use "esnext" (no conversion*) when using a bundler, or "commonjs" for node;esModuleInterop
is an es-modules "quirk" fix;
Type-checking options:
strict
turns on all of the latest type-checking features (very important);noImplicitAny
disables one specially annoying feature with a good trade-off (personal opinion);
lib
is entirely optional and allows tuning of which global-environment types are available; For instance, the default setting includes "dom", but you'd like to disable "dom" types in a node.js project.
Concluding it, we got:
Last updated