Dynamic Imports that are marked external are hoisted about webpack

[alexander-akait]

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

[alexander-akait]

Also you can specify the type for an each item using https://webpack.js.org/configuration/externals/#string

[mohamedmansour]

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.

[alexander-akait]

@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.

[mohamedmansour]

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.

[alexander-akait]

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