tsconfig.json Generator

Results

tsconfig.json has well over a hundred compiler options and every TypeScript tutorial shows a different combination. This generator sticks to the ones that matter for most projects: target, module, moduleResolution, jsx, the common boolean flags (strict, esModuleInterop, skipLibCheck and friends) and the outDir/rootDir folders. The tsconfig.json preview updates live as you change options; copy it into the root of your project and you have a clean config without the dead options most boilerplates ship.

How the config is built

  1. 1

    Pick target and module

    The JavaScript version tsc emits (ES2015 through ES2023, or ESNext) and the module system (CommonJS, ES2015/ES2020/ES2022, ESNext, Node16, NodeNext).

  2. 2

    Choose moduleResolution and JSX

    bundler for Vite/webpack projects, node16/nodenext for modern Node, node or classic for legacy setups. Set jsx to react-jsx for modern React, or leave it on none to omit the key.

  3. 3

    Toggle the flags

    strict, esModuleInterop, skipLibCheck, resolveJsonModule, allowJs, declaration, sourceMap and forceConsistentCasingInFileNames as simple checkboxes.

  4. 4

    Set the folders

    outDir and rootDir, preset to ./dist and ./src. include and exclude are fixed to src/**/* plus node_modules and dist.

  5. 5

    Copy the generated tsconfig

    The JSON preview updates live; one click copies it, ready to drop into your project root as tsconfig.json.

The options this generator writes

Option Default here What it does
target ES2022 JavaScript version of the emitted code. ES2022 is safe for current browsers and Node; pick an older target only for legacy environments.
module ESNext Module syntax of the output. Use NodeNext/Node16 for Node ESM projects, CommonJS for legacy Node.
moduleResolution node How imports are located. Prefer bundler with Vite/webpack/esbuild and node16/nodenext with modern Node; node (node10) is the legacy behavior.
jsx omitted Only written when you pick a mode. react-jsx for React 17+, preserve when a bundler transforms the JSX.
strict true Turns on the whole strict family of checks. Keep it on for new projects.
esModuleInterop true Fixes default imports from CommonJS packages.
skipLibCheck true Skips type-checking .d.ts files; much faster compiles, rarely hides real bugs.
forceConsistentCasingInFileNames true Rejects imports whose casing differs from the file on disk (a classic macOS-to-Linux breakage).
resolveJsonModule true Lets you import data from "./data.json".
allowJs false Allows .js files in the compilation; useful mid-migration.
declaration false Emits .d.ts files; turn it on when publishing a library.
sourceMap false Emits .js.map files for debugging.
outDir / rootDir ./dist / ./src Where compiled output goes and where the sources live.
baseUrl "." Always written, so a hand-added paths block resolves from the project root.

The exact default output

Leave every control untouched and this is the file you get:

{
    "compilerOptions": {
        "target": "ES2022",
        "module": "ESNext",
        "moduleResolution": "node",
        "strict": true,
        "esModuleInterop": true,
        "skipLibCheck": true,
        "forceConsistentCasingInFileNames": true,
        "resolveJsonModule": true,
        "allowJs": false,
        "declaration": false,
        "sourceMap": false,
        "outDir": "./dist",
        "rootDir": "./src",
        "baseUrl": "."
    },
    "include": [
        "src/**/*"
    ],
    "exclude": [
        "node_modules",
        "dist"
    ]
}

Pick a jsx mode other than none and a "jsx" entry is appended to compilerOptions.

Strict mode: what it actually turns on

strict: true is an umbrella flag that enables the whole strict family, including noImplicitAny, strictNullChecks, strictFunctionTypes, strictBindCallApply, strictPropertyInitialization, noImplicitThis, useUnknownInCatchVariables and alwaysStrict. New projects should start with all of them on: retrofitting strictness later is painful.

Common mistakes

  • Setting module: "CommonJS" for a Node ESM project. If your package.json says "type": "module", use NodeNext for both module and moduleResolution.
  • Using tsc as a bundler. It is a compiler and type checker. Use Vite/esbuild/SWC for builds and tsc --noEmit for type checks.
  • Compiling everything. Without an include list TypeScript picks up every .ts file it can see. The generated config always writes include: ["src/**/*"] and excludes node_modules and dist, so you are covered.
  • Needing more than the config offers. This generator deliberately stays minimal. Options like lib, paths, isolatedModules or noEmit are easy to add by hand once the base file is in place.

Frequently Asked Questions

For monorepos and multi-package projects, yes: one base file with the shared options and each package extending it via “extends”. For a single-project repo, one tsconfig.json like the generated one is simpler.

Introduced in TypeScript 5.0 for projects built with Vite, webpack or esbuild. It matches how bundlers actually resolve imports, without the ESM file-extension rules of node16/nodenext. For code executed directly by Node, prefer node16 or nodenext.

Not with a dedicated control, no. The generated file always sets baseUrl to “.”, so you can paste a paths block right below it, for example “@/*”: [“src/*”], and it will resolve from the project root.

Usually not, which is why this generator omits it: target implies a matching set of library types. Override lib by hand only for special cases, such as DOM APIs in a Node project or WebWorker types.

No sign-up is needed and nothing is saved. Your selections are used only to render the config preview, and in the step-by-step view they also travel in the page URL, so a finished config is easy to bookmark or share.

Related Tools

Tool available in other languages