next tsconfig

tsconfig for Next.js

Generate a strict TypeScript config for a Next.js App Router project.

Next.js defaults

A Next.js tsconfig should preserve the framework's generated types, JSX handling, bundler resolution, and strict settings when your team is ready for them.

Good starting point

Use strict mode for new projects, keep noEmit enabled, and include `.next/types/**/*.ts` so route and framework types remain available.

App Router includes

Next.js generates framework types during development and build. Keep generated type paths in `include` so route params, metadata helpers, and framework declarations stay visible to TypeScript.

{
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"]
}

Strict mode choice

Use strict mode for new App Router projects. For older apps, enable strict mode after checking server components, route handlers, and shared UI packages with the same compiler settings.

Path aliases

Keep `baseUrl` and `paths` explicit. Root aliases such as `@/*` are useful, and many app teams also add focused aliases for components, utilities, and hooks. In monorepos, prefer a shared base config plus package-level overrides so aliases do not hide package boundaries.

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"],
      "@components/*": ["./src/components/*"],
      "@utils/*": ["./src/utils/*"]
    }
  }
}

Extends and test configs

Use `extends` when a monorepo has a shared `tsconfig.base.json`, then keep app or package differences local. Split `tsconfig.test.json` when Vitest, Playwright, or Node test files need Node types or wider include globs than the app config.

{
  "extends": "../../tsconfig.base.json",
  "compilerOptions": {
    "types": ["vitest/globals", "node"]
  },
  "include": ["src", "tests", "playwright.config.ts"]
}

Before committing

Run `next build` and `tsc --noEmit` if your workflow includes an explicit typecheck. Compare the generated tsconfig with existing framework defaults before deleting includes, changing decorator mode, or moving test files to a separate config.

Next.js tsconfig settings

Setting	Recommended value	Why it matters
moduleResolution	`bundler`	Matches App Router compilation and extensionless imports.
jsx	`preserve`	Lets Next.js own JSX transforms.
noEmit	`true`	Keeps TypeScript as a checker while Next owns output.
include	App files plus `.next/types/*/.ts`	Preserves generated framework and route types.

Use FrameworkKit to generate the starter code, then review the output before shipping it in production.

Generate with tsconfig Builder

tsconfig resources

tsconfig Builder

Generate TypeScript config presets for Next.js, Vite, Node, libraries, and strict mode projects.

tsconfig examples

Compare framework-aware TypeScript config starters before adapting your own project config.

moduleResolution bundler vs node16

Choose TypeScript module resolution for bundlers, Node ESM, libraries, and monorepos.

tsconfig Builder vs manual config

Decide when a generated config starter is enough and when a project needs manual compiler options.

FAQ

What should moduleResolution be for Next.js?

Use `bundler` for modern Next.js apps because Next owns bundling and supports extensionless imports through its compiler pipeline.

Should Next.js tsconfig use noEmit?

Yes. Next.js emits application output, so TypeScript usually runs as a type checker with `noEmit: true`.

Can I enable strict mode in an existing Next.js app?

Yes, but migrate in stages if the app is large. Start with shared types, route handlers, and high-risk API boundaries.

Why include .next/types in tsconfig?

Generated Next.js types can improve framework-aware checking for routes and app files, so removing them can reduce type coverage.

Related comparisons

tsconfig Builder vs Manual Config

Compare generated tsconfig presets with hand-written TypeScript configuration.