tsconfig Builder

Runs locally in your browser
Input
Output
{
  "compilerOptions": {
    "target": "ES2017",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "strict": true,
    "noEmit": true,
    "module": "esnext",
    "moduleResolution": "bundler",
    "jsx": "react-jsx",
    "paths": {
      "@/*": [
        "./src/*"
      ]
    },
    "skipLibCheck": true,
    "esModuleInterop": true
  },
  "include": [
    "next-env.d.ts",
    "**/*.ts",
    "**/*.tsx",
    ".next/types/**/*.ts"
  ],
  "exclude": [
    "node_modules"
  ]
}
tsconfig builder

TypeScript config generator

Build a tsconfig starter from framework-aware presets instead of copying random compiler options. FrameworkKit keeps the output readable so teams can review and adapt it.

Presets

Start from a preset for Next.js, Vite, Node services, or package libraries, then tune strict mode, decorator mode, and path aliases.

  • Next.js App Router friendly includes.
  • Vite/browser settings with class field semantics.
  • Node service ESM or CommonJS targets and libs.
  • Legacy decorator metadata for NestJS or TypeORM, kept separate from standard TS 5 decorators.

When to use it

Use the builder for new projects, framework migrations, or strict mode exploration before committing a compiler policy to the repo.

Preset decision guide

Choose Next.js when the app relies on App Router generated types, Vite when the browser bundler owns output, Node when emitted JavaScript runs directly in a service, and library when published packages need declaration output.

  • Next.js keeps `noEmit`, React JSX, bundler resolution, and `.next/types` includes.
  • Vite keeps DOM libs, modern modules, bundler-friendly imports, and `useDefineForClassFields`.
  • Node presets make ESM vs CommonJS runtime module behavior explicit.
  • Library presets emit declarations and `composite` metadata for project references.

Strict mode rollout

The builder is useful when a team wants to compare strict and relaxed settings before changing CI. Treat the generated tsconfig as a policy draft, then run TypeScript against representative app, test, and build files.

Monorepo review

For monorepos, generate the closest app preset first, then split shared base options into `tsconfig.base.json` and let package configs extend it with paths such as `../../tsconfig.base.json`. Keep path aliases, declaration output, `composite`, and runtime module resolution visible in review.

Test config review

Use a separate `tsconfig.test.json` when Vitest, Playwright, build scripts, or Node test files need different `types`, `include`, or module settings than browser app code.

What this tool does

Generate a TypeScript compiler configuration starter for a specific framework or runtime.

Start a strict Next.js app

Generate a readable App Router tsconfig with framework includes intact.

Compare runtime presets

Switch between Next.js, Vite, Node, and library defaults before committing config.

Explain compiler choices

Use the generated preset as a team-friendly baseline for TypeScript policy.

tsconfig resources

Use examples and deep dives when choosing TypeScript compiler settings for real project runtimes.

Privacy model

tsconfig Builder runs in your browser. FrameworkKit does not send tool input or generated output to a server in the current app.

FAQ

Is this a replacement for reading TypeScript docs?

No. It creates a practical starter config for common project shapes so teams can review and adapt it faster.

Does the generated tsconfig run locally?

Yes. Preset generation happens in the browser and the output is plain JSON you can copy into your project.

Which frameworks are supported?

The current builder covers Next.js, Vite, Node services, and package library presets.

Which decorator mode should I choose?

Use legacy decorators for NestJS, TypeORM, and other DI/reflection stacks that need experimentalDecorators plus emitDecoratorMetadata. Use standard decorators for TypeScript 5+ code that does not rely on legacy metadata.

Should tests use the same tsconfig?

Often no. Vitest, Playwright, and Node test files may need a separate tsconfig.test.json with different includes, globals, or Node types.