TypeScript New Added 10 September 2026

TypeScript: Option 'module' must be set to 'NodeNext'

moduleResolution and module are not independent: the Node16 and NodeNext resolution modes read package.json exports and the type field, and only the matching module setting emits code that agrees with them. Copying a moduleResolution line from a bundler config into a Node project is the usual way to land here.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix

// Node project, ESM or CommonJS decided by package.json "type"
{
  "compilerOptions": {
    "module": "nodenext",
    "moduleResolution": "nodenext",
    "target": "es2022"
  }
}

// Bundler project (Vite, webpack, esbuild): the other valid pair
{
  "compilerOptions": {
    "module": "esnext",
    "moduleResolution": "bundler"
  }
}

# See what the compiler ended up with after extends and defaults
npx tsc --showConfig | grep -Ei '"(module|moduleResolution|target)"'

# NodeNext also makes relative imports need the .js extension in ESM
# import { x } from "./util.js";   // even though the file is util.ts

How to diagnose TypeScript errors

TypeScript errors are the compiler describing a mismatch between what you declared and what you did. Nearly all of them fall into assignability (this shape is not that shape), missing declarations (a JavaScript package with no types), or strict null checks (a value can be undefined on a path you did not handle). Casting with as or any silences the message without fixing the underlying mismatch, which usually reappears at runtime.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

Read the error from the innermost "Types of property X are incompatible" line outward. That nested line names the actual mismatch.
For missing declarations, try npm i -D @types/<pkg> first; if none exists, write a minimal .d.ts rather than reaching for any.
Narrow rather than assert. A type guard, an in check, or an early return preserves safety where as discards it.
Use tsc --noEmit --pretty to check the whole project; editors sometimes use a different TypeScript version than the build.
Check strict, skipLibCheck and moduleResolution in tsconfig when errors appear only in CI or only in the editor.

Tools worth reaching for

tsc --noEmit
ts-node / tsx
@types/* packages
typescript-eslint
editor TS version selector

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

typescriptlang.org

Related TypeScript errors

See all 19 TypeScript errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.