-
Notifications
You must be signed in to change notification settings - Fork 13k
Description
a.k.a. --moduleResolution node
The problem with --moduleResolution node
was that it was a fixed target that implied it modeled the latest Node behavior. In reality, we had to introduce a --moduleResolution nodenext
.
--moduleResolution node
is very out-of-date and lacks many behaviors from newer versions of Node.js - for example, exports
, imports
, and type
from package.json
; distinctions between CJS and ESM files; requirements on extensions in relative imports; and more. This often leads to tons of misconfigured packages shipped, and the problem has gotten so bad that @andrewbranch built https://arethetypeswrong.github.io/.
Typically if a user is using --moduleResolution node
, it is because they are trying to write:
- a Node.js app/library
- a web project which needs to have its
node_modules
bundled
Node.js apps should almost all be using --module nodenext
, which implies --moduleResolution node
. This captures all the modern behaviors that --moduleResolution node10
is missing.
{
"compilerOptions": {
- "module": "commonjs"
+ "module": "nodenext"
}
}
Web projects that "rely" on --moduleResolution node
are often taking advantage of CommonJS-specific behaviors, like extensionless imports, or have issues building without fallbacks to types
/main
instead of exports
in package.json
. Often these projects are using esnext
emit with an explicit opt-in to --moduleResolution node/node10
, but they also may be using commonjs
and getting node10
as the default resolution. These projects should all switch to --module esnext
/--moduleResolution bundler
.
{
"compilerOptions": {
- "module": "commonjs"
+ "module": "esnext"
+ "moduleResolution": "bundler"
}
}
In TypeScript 7.0, --moduleResolution node/node10
will not be supported. It is too big of a footgun and doesn't warrant the complexity.
In TypeScript 6.0, --moduleResolution node/node10
will be deprecated, and TypeScript will issue an error unless --ignoreDeprecations
is specified.
Additionally, in both versions, projects using --module commonjs
will get the behavior of bundler
, which approximates an overly-permissive version of CommonJS, but which understands and prefers more recent Node.js behaviors.
See more discussion on this topic and other 6.0 deprecations/changes at #54500.