| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
…ack#18315) When usedExports is set to 'global', async entries (workers) were not being processed with forceSideEffects: true, causing CommonJS modules with self-reference dependencies to throw 'Self-reference dependency has unused export name' errors. This fix ensures async entries are always processed with forceSideEffects regardless of global mode, using undefined (global runtime) when global mode is enabled.
🦋 Changeset detectedLatest commit: eb2f352 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 |
Sorry, something went wrong.
CodSpeed Performance ReportMerging #20251 will not alter performanceComparing samarthsinh2660:fix/18315-worker-self-reference (eb2f352) with main (24e3c2d) Summary✅ 72 untouched |
Sorry, something went wrong.
|
Thanks |
Sorry, something went wrong.
|
This PR is packaged and the instant preview is available (557582a). Install it locally:
npm i -D webpack@https://pkg.pr.new/webpack@557582a
yarn add -D webpack@https://pkg.pr.new/webpack@557582a
pnpm add -D webpack@https://pkg.pr.new/webpack@557582a |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Summary
Fixes #18315.
When optimization.usedExports is set to "global", async entry blocks (e.g. web workers created via new Worker(new URL(...))) were not processed with forceSideEffects: true during export usage analysis.
In that mode, CommonJS modules that contain self-reference dependencies (handled by CommonJsSelfReferenceDependency) could end up with exports not being marked as used, which then triggers:
Error: Self-reference dependency has unused export name: This should not happen
This change ensures that async entries are always analyzed with forceSideEffects: true. When the analysis runs in global mode, the async entry is analyzed using runtime: undefined (global runtime), aligning it with the rest of the global used-exports analysis.
What kind of change does this PR introduce?
fix
Did you add tests for your changes?
Yes. Added a regression test case:
It reproduces the failure by importing a CommonJS module with a self-reference dependency from within a worker when optimization.usedExports: "global" is enabled.
Does this PR introduce a breaking change?
No.
If relevant, what needs to be documented once your changes are merged or what have you already documented?
No documentation changes.