Repository navigation
fix: expose exports of all entry modules in library output - #21662
webdevelopersrinu wants to merge 1 commit into
Conversation
When an entry is an array of modules and a library output is configured, only the exports of the last entry module were flagged as used and exposed on the library. Exports of all earlier entry modules were tree-shaken away and silently dropped. The fix stays entirely in the library plugin layer: - AbstractLibraryPlugin gains an opt-in finishAllEntryModules mode that flags the exports of every entry dependency as used, and a helper that renders startup code merging the exports of all entry modules of the chunk into the final library exports object. Later entry modules win on export name conflicts, preserving the documented last-entry-wins semantics. Merging is skipped when startup is delayed by depending chunks or when entry modules are inlined. - AssignLibraryPlugin (var, assign, this, window, self, global, commonjs, commonjs2) and ExportPropertyLibraryPlugin (amd, umd, system, jsonp) opt in. - module/modern-module and commonjs-static keep their current behavior, since their export lists are generated statically from the last entry module. Fixes webpack#15936
🦋 Changeset detectedLatest commit: a4dc34f The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
👋 Hi there! This PR was automatically flagged and closed by our quality checks. If you believe this was a mistake, please review our contributing guidelines |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (8)
📝 WalkthroughWalkthroughChangesThe library plugins now merge exports from all eligible synchronous modules in an array entry. Later modules override earlier exports with the same name. A regression case validates aggregation and precedence. Multi-entry library exports
Fixed issue severity: Medium Possibly related PRs
Comment |
|
@alexander-akait @avivkeller I'd like to respectfully ask for a human review of this closure — I believe the quality bot is flagging my account history (new contributor, and #21661 which was closed only because my CLA hadn't processed yet), not this submission. Everything the bot previously flagged is resolved: EasyCLA is green, the changeset is included, the commit and title follow conventional format. On the substance: this addresses #15936 ( If there's anything about the approach you'd like changed, I'm happy to rework it. Could this be reopened for review? |
|
It is a breaking change, we need to make it under the option and it requires discussions firstly and compare how other tools work here, let’s close now, feel free to start a discussion in the issue |
Fixes #15936
Problem
With
entry: ["./a.js", "./b.js", "./c.js"]and a library output, only the last entry module's exports were flagged as used — exports of earlier entries were tree-shaken away and silently dropped from the library.Solution (library plugin layer only)
AbstractLibraryPlugingains an opt-infinishAllEntryModulesmode that flags exports of every entry dependency as used, plus a helper that renders startup code merging all entry modules' exports into the library exports object.AssignLibraryPlugin(var/assign/this/window/self/global/commonjs/commonjs2) andExportPropertyLibraryPlugin(amd/umd/system/jsonp) opt in.module/modern-moduleandcommonjs-staticintentionally keep current behavior (their export lists are generated statically from the last entry module).Testing
test/configCases/library/issue-15936-entry-array-exports— fails on main, passes with this change (multi-entry exposure + conflict semantics).librarycategory of ConfigTestCases: zero new failures vs baseline.Summary by CodeRabbit
New Features
Bug Fixes
Tests
Documentation