Allow --module bundler --moduleResolution commonjs
#62320
Merged
+181
−241
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There was a problem hiding this comment.
Pull Request Overview
This PR allows the combination of --module bundler with --moduleResolution commonjs, which was previously prohibited with a program error. This change supports users who transpile their TypeScript code to CommonJS before bundling, particularly those using tools like Webpack's ts-loader with CommonJS module compilation settings.
Key changes:
- Removes the restriction preventing
--moduleResolution bundlerfrom being used with--module commonjs - Updates error messages to include "commonjs" as a valid module option with bundler resolution
- Adds comprehensive test coverage for the new combination of settings
Reviewed Changes
Copilot reviewed 23 out of 23 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
src/compiler/program.ts |
Updates validation logic to allow --module commonjs with --moduleResolution bundler |
src/compiler/diagnosticMessages.json |
Updates error message text to include "commonjs" as a valid option |
tests/cases/conformance/moduleResolution/bundler/bundlerCommonJS.ts |
New test file demonstrating CommonJS module resolution with bundler |
tests/cases/conformance/moduleResolution/bundler/bundlerOptionsCompat.ts |
Updates existing test to use "nodenext" instead of "commonjs" |
| Multiple baseline files | Updates test baselines to reflect the new allowed combination and updated error messages |
jakebailey
approved these changes
Aug 22, 2025
andrewbranch
commented
Aug 22, 2025
Comment on lines
+34
to
+35
| // @Filename: /real-imports.mts | ||
| import { x } from "pkg"; // Error |
There was a problem hiding this comment.
As of #57896 (TS 5.6), .mts and .cts extensions override the --module setting. Since this import will emit as an import, and the package has only a require entrypoint, the resolution fails.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prerequisite for #62200
This has worked in a coherent way since
--module preservewas implemented, but was prohibited with a program error.--moduleResolution bundler(like every other modern TS resolution mode) resolves package.json"exports"conditions according to the output module syntax being emitted. So in--module commonjs, imports in .ts and .js files always resolve with the"require"condition set.This combination of settings is very rarely going to be what people actually want, and is mostly intended as a "my code works, don't bother me" upgrade path for users on
--module commonjs --moduleResolution: node. (More poignantly, it doesn't seem like deprecating--module commonjsis an option at this point, and with--moduleResolution node10going away, that leaves nomoduleResolutionsettings left that are legal withcommonjs.) However, it's also the correct settings for anyone transpiling their code to CommonJS before resolving imports through a bundler. This includes Webpack ts-loader users who have--module commonjsin their ts-loader tsconfig. However, you should not use this combination of settings just because you set your bundler's output to emit a CommonJS module, so our docs / blog post need to be intentional about highlighting this.