-
Notifications
You must be signed in to change notification settings - Fork 13.1k
Allow --module bundler --moduleResolution commonjs
#62320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
| // @Filename: /real-imports.mts | ||
| import { x } from "pkg"; // Error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Co-authored-by: Andrew Branch <[email protected]> Co-authored-by: Andrew Branch <[email protected]>
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.