Skip to content

Deprecate, remove --moduleResolution node10 #62200

@DanielRosenwasser

Description

@DanielRosenwasser

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.

Metadata

Metadata

Assignees

Labels

Breaking ChangeWould introduce errors in existing codeCommittedThe team has roadmapped this issueFix AvailableA PR has been opened for this issueSuggestionAn idea for TypeScript

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions