-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Description
Feature request
What is the expected behavior?
CommonJS code allows the usage of require, and so the corresponding webpack rule type javascript/auto will transform require.resolveWeak into the corresponding runtime code.
ESM code does not allow the usage of require, and so javascript/esm type does not transform require.resolveWeak, as we don't expect to see require in this context.
Still, libraries like @lodable/components or react-loadable leverage this require.resolveWeak capability to implement their code-splitting abstractions. When generating ESM code that use them, we end up with require.resolveWeak inside ESM, which webpack does not understand by default. This creates runtime failures.
What is motivation or use case for adding/changing the behavior?
As far as I know multiple options can mitigate the issue:
-
not using ESM
-
not using those libraries
-
forcing
javascript/autofor the concerned ESM files (see issue here){ test: /\.js$/, include: /path\/to\/esm\/files\/with\/resolveWeak/, type: 'javascript/auto', }
No option is perfect here:
- is not future-proof
- means that we lose key features of those libs like server-side rendering chunk extractions (eg.
@loadable/server) - requires extra config (and maybe it has negative side effects on other aspects like performances?)
How should this be implemented in your opinion?
Webpack started to leverage import.meta, which is free to use, to implement import.meta.webpackContext, for example.
Can we imagine following this path to port the resolveWeak capability to javascript/esm also? This is also mentioned in this comment.
This way, code historically leveraging require.resolveWeak will be able to migrate to import.meta.resolveWeak or something similar when bundled in ESM.
Are you willing to work on this yourself?
I can help, but I've never contributed to webpack so this might be a very challenging tasks for me 😅
I'm probably better suited to do update PRs on https://github.com/gregberge/loadable-components/ and https://github.com/swc-project (loadable plugin).