fix: library module without export statement#18176
fix: library module without export statement#18176hai-x wants to merge 1 commit intowebpack:mainfrom hai-x:hai-x/fix-issue-18056
Conversation
…ion.providedExports to false
|
For maintainers only:
|
| const { library } = output; | ||
| if (providedExports === false && library && library.type === "module") { | ||
| // only flag the entry module | ||
| let connection = Array.from(moduleGraph.getIncomingConnections(module)); |
There was a problem hiding this comment.
Is there any other better way to determine whether it is an entry module during finishModules stage?
|
/cc @sokra |
| options.optimization.providedExports || | ||
| (options.optimization.providedExports === false && | ||
| options.output.library && | ||
| options.output.library.type === "module") |
There was a problem hiding this comment.
I dont' think we should rely on such things, we need to improve logic inside the plugin itself
There was a problem hiding this comment.
Yes, i think this would also destroy the meaning of the config, but 'libraryType: module' does rely on the module's exportsInfo, maybe we need to simply record export by sth like 'exportsInfo' for 'output: module'.
There was a problem hiding this comment.
Do you have any other suggestions? I'd be glad to read the related code and fix this issue.
There was a problem hiding this comment.
Yes, i think this would also destroy the meaning of the config, but 'output: module' does rely on the module's exportsInfo, maybe we need to simply record export by sth like 'exportsInfo' for 'output: module'.
And it seems that users rarely set 'providedExport' to false because of the performance issues of it.
There was a problem hiding this comment.
I will look deeply later
|
We close this PR and attempt to address it using another approach from #18056 (comment). |
fixes #18056
What kind of change does this PR introduce?
When library === module and providedExport === false we also flag exportsInfo by FlagDependencyExportsPlugin but only for the entry module. Not sure if this is the optimal solution, but I tested it and it is indeed feasible.
Did you add tests for your changes?
Yes
Does this PR introduce a breaking change?
No
What needs to be documented once your changes are merged?
No