Comments (8)
I want to say it is not a bug, just change externalsType: 'module'
to externalsType: "import",
.
I think we should add a new value for externalsType
- import-module
/module-import
(maybe the best name) and set it by default for ES modules, i.e. keep import(...)
and import ... from "module";
for externals how they were written
from webpack.
Also you can specify the type for an each item using https://webpack.js.org/configuration/externals/#string
from webpack.
Thank you @alexander-akait , that actually solves the hoisting, but it brings that hoisting still back to the main bundle into a function. For example, index.ts
dynamically imports lazy.ts
, and lazy.ts
dynamically imports an external named external.ts
. The definition of externals
is hoisted to the main bundle index.js
, instead it should have been inside external.js
I don't think we need another externalsType
, why would someone who specifies module
would want the imports hoisted for dynamic imports? That feels wrong. If they want it to be hoisted, then define them as import "foo"
instead of import("foo")
. It feels more like a bug. By definition in webpack docs: webpack will output ECMAScript module syntax whenever possible
My recommendation would be to keep externalsType
as module
and don't transform it, just keep it in its place.
from webpack.
@mohamedmansour No, it is not a bug, I can't find a discussion about it, but there was already a question about it here, there are scenarios when developers want to hoist (preload big modules in the first run), some want to load dynamically (lazy evaluation), especial in diffucult applications (you can improve perf in some cases, for example some modules can take a lot of time on import but you used them in rare cases and you can't change vendor library code), that is why I said, we need the another value to allow to keep dynamic import as dynamic and static as static. The same logic works for other values of the externalsType
option.
from webpack.
It is actually a more serious bug when we move to import
it breaks the natural ESM sequence since our web app is strictly ESM (esnext, modules). So we cannot use it.
We need true browser platform ESM outputs. In the example below, chromejs
is marked external. And we get the error:
Uncaught TypeError: Cannot read properties of undefined (reading 'log')
For example, chrome.js
is marked external:
index.ts
import './chrome.js';
import 'app.js';
chrome.js
window.chrome = {
'log': () => console.log('logger');
}
app.js
window.chrome.log();
To your question, when developers want to hoist big modules, can't they just do the following which solves that scenario:
import 'big-module.js';
async function OnClick() {
await import('small-module.js');
}
Since big-module
is marked as external, it will not bundle it.
Doing some re-arrangement to assume all "dynamic" imports get hoisted to the top, breaks a core use case of dynamic imports.
from webpack.
As I said above we just need a new value - import-module
, we can't keep them as is when you have import
or module
, because it will be breaking change and can break a lot of configurations
from webpack.
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.
from webpack.
Bump (activity)
from webpack.
Related Issues (20)
- Implement ability to use "node:" prefixes for Node.js core modules HOT 1
- mangled exports breaks with destructuring assignment of JSON imports HOT 7
- there are confusing JDocs code
- Potential bug issues
- Webpack is not resolving node_modules specified in `resolve.modules` property.
- Dynamically loading chunks
- [Code implementation issues] ArrayQueue
- [feature] create cli HOT 3
- Not able to build node script
- bootstrap:27 Uncaught TypeError: __webpack_require__.nmd is not a function
- Self-reference dependency has unused export name when imported inside of a web worker
- support `import.meta.dirname` and `import.meta.filename` HOT 2
- <!-- identifier: admin-actions -->
- Remote into Web Component from React giving an error saying " Module does not exist in container"
- Multiple DefinePlugin instances cause aggressive cache invalidation due to collisions HOT 7
- import .scss build to js, the exported mapping is inconsistent with the usage【Urgent!!】
- Unused code elimination and deduplication is not applied when using sass's api: 'legacy' setting
- In cli, why no option named "--output-file-name" ?
- Need help with migrating a custom middleware from v3 to v5 of webpack-dev-server
- Module federation: the usage of "dynamic remotes" will cause blank screen when working with `runtimeChunk`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webpack.