Configuring TypeScript Strict Mode in a Next.js Project

TypeScript strict mode improves type safety and reduces runtime errors in Next.js applications. It enforces stricter checks that catch common errors at compile time rather than at runtime.

Environment

Next.js 16+ with App Router (app/ directory) or Pages Router (pages/ directory)
TypeScript 5
A standard tsconfig.json generated by create-next-app

Prerequisites

A working Next.js project with TypeScript enabled. Confirm TypeScript by checking that tsconfig.json exists and typescript is listed in package.json dependencies.

Problem

Without strict mode, TypeScript allows implicit any types, optional parameters that may be undefined, and uninitialized variables. These omissions lead to runtime errors that are harder to diagnose than compile-time errors. Strict mode forces explicit types and null checks.

Working approach

Step 1: Enable strict mode in tsconfig.json

In the tsconfig.json file at the project root, set:

{
  "compilerOptions": {
    "strict": true
  }
}

If using Next.js with the App Router, also confirm noEmit remains enabled (default for Next.js):

{
  "compilerOptions": {
    "strict": true,
    "noEmit": true
  }
}

Step 2: Review and fix errors

After enabling strict mode, run the type check:

npx tsc --noEmit

Review errors in order:

Parameter implicitly has an 'any' type: add an explicit type annotation.
Object is possibly 'undefined': add a null check or optional chaining before use.
Property does not exist on type: confirm the object shape or use a type guard before accessing the property.
Missing return types in exported functions: add return type annotations when the function is reused across files.

Step 3: Fix common strict-mode issues in Next.js

In app/ components:

Use use client only when client-side hooks are required. Strict mode does not change this requirement but catches missing hook rules more reliably.
For server components that receive props, define the props interface explicitly rather than relying on inferred types.
For dynamic routes ([slug]), confirm the parameter type matches the expected value before using it.

In Pages Router (pages/):

Confirm page props match the GetServerSideProps or GetStaticProps return type.
Confirm global type augmentations in global.d.ts or next-env.d.ts match the strict-mode rules.

Common failure modes

Enabling strict mode produces many errors in an existing codebase: fix incrementally (enable noImplicitAny, strictNullChecks, strictFunctionTypes, strictBindCallApply, strictPropertyInitialization, noImplicitThis, alwaysStrict individually) rather than all at once if needed.
next build fails with type errors: these are the same errors npx tsc --noEmit reports. Fix all errors before deploying.
Type errors in node_modules: these are usually false positives. Add specific exclusions in tsconfig.json only for libraries with incorrect .d.ts definitions, not as a workaround for missing types in application code.
noEmit disabled accidentally: Next.js requires noEmit: true so TypeScript does not emit .js files that conflict with the build pipeline. Confirm the setting remains true after any manual edit.

Verification

Confirm tsconfig.json contains "strict": true.
Run npx tsc --noEmit. Confirm 0 errors.
Run npm run build. Confirm the production build passes.
Confirm node_modules errors are not masked by incorrect exclusions.

Caveats

Strict mode improves type safety but does not enforce runtime validation. Always validate user input at the application boundary (API routes, forms) independently of TypeScript types.
Strict mode must not be enabled solely for appearance or SEO purposes. It serves a real technical purpose: reducing runtime errors through compile-time checks.

See web-development/deployment/deploy-nextjs-vercel-env for environment-related differences that affect server-side execution (production builds have stricter environment requirements).
See troubleshooting/databases/database-connection-production for diagnosing database connection failures in production deployments (production builds enforce stricter checks that can reveal hidden configuration errors).