Repository navigation
Self-reference dependency has unused export name when imported inside of a web worker #18315
Description
Bug report
What is the current behavior?
When a web worker imports a CommonJS module with a self reference dependency, webpack throws Error: Self-reference dependency has unused export name: This should not happen.
This happens when usedExports is set to "global".
I think this is related:
#12646 / #12648
It seems like that fix works when usedExports is not set to "global", but it doesn't work when usedExports: "global" is set.
If the current behavior is a bug, please provide the steps to reproduce.
Repro: https://github.com/pgoldberg/webpack-self-reference-dependency-worker-bug
What is the expected behavior?
Webpack should not throw an error
Other relevant information:
webpack version: 5.91.0
Node.js version: any
Operating System: any
Additional tools:
Activity
bbb169 commentedon Jul 8, 2024
Hello, I did so work on this issue, and find out the process of bug occurrence， but I got no clue how to solve it, could anyone please give me some suggestion
Should I just ignore this error in CommonJsSelfReferenceDependency when config 'usedExports'?
@alexander-akait
alexander-akait commentedon Jul 11, 2024
Hm, you can send a PR and we will look our tests
webpack-bot commentedon Oct 16, 2024
This issue had no activity for at least three months.
It's subject to automatic issue closing if there is no activity in the next 15 days.
pgoldberg commentedon Oct 16, 2024
Please keep open
sarveshadk commentedon Nov 7, 2024
Create a Webpack configuration with the usedExports: "global" option set.
Import a CommonJS module that has a self-reference or circular dependency inside a Web Worker.
Webpack will throw the error: Self-reference dependency has unused export name: This should not happen.
Expected Behavior
Webpack should handle self-referencing or circular dependencies correctly without throwing an error, even with usedExports: "global" set.
The usedExports: "global" optimization should work without causing issues in such cases.
Potential Workaround
Since this issue might be related to the specific optimizations when usedExports is set to "global", you could try the following:
Use a different optimization setting: Instead of "global", try using "false" or "true" for usedExports, as this could bypass the issue by not triggering the optimization that causes the error.
optimization: {
usedExports: "false", // or "true"
}
Ensure the module structure is not self-referencing: If possible, refactor the CommonJS module to avoid circular dependencies or self-referencing exports, though this might not always be feasible depending on your codebase.
Use a different bundling strategy: Depending on your setup, consider testing alternative bundlers or adjusting your worker-related configurations to avoid relying on usedExports: "global" if that is causing the issue.
Update Webpack or Patch: Since the issue is potentially related to a Webpack bug (#12646, #12648), check if there are any newer Webpack versions or patches that address this problem. If not, you might need to apply a custom fix or rollback to a version where the issue isn't present.
Additional Resources
Review the issues on Webpack's GitHub related to circular dependencies and self-referencing modules.
Check Webpack's documentation for any updates on usedExports optimization and its behavior with CommonJS and web workers.
If you're able to isolate the issue in a minimal example (as you did in your repo), it can be helpful to provide it to the Webpack team for further investigation.
webpack-bot commentedon Feb 21, 2025
Issue was closed because of inactivity.
If you think this is still a valid issue, please file a new issue with additional information.
fix: process async entries with forceSideEffects in global mode (webp…