-
-
Notifications
You must be signed in to change notification settings - Fork 8.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add new external type "module-import" #18620
Conversation
For maintainers only:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can preserve import ... from '...'
and import()
using instanceof
without extra hooks like here https://github.com/webpack/webpack/blob/main/lib/ExternalModuleFactoryPlugin.js#L120
Thanks for the suggestion. IIUC, does the code snippet demonstrate whether it meets your suggestions? Or keep the original method that removing the dep from module block. // lib/ExternalModuleFactoryPlugin.js
if (
type === "module-import" &&
dependency instanceof ImportDependency
) {
dependency.runTemplate = false;
}
callback(
null,
new ExternalModule(
externalConfig,
type || globalType,
dependency.request,
dependencyMeta
)
);
// lib/dependencies/ImportDependency.js
if (dep.run_template === false) {
return;
}
const content = runtimeTemplate.moduleNamespacePromise({
chunkGraph,
block: block,
module: /** @type {Module} */ (moduleGraph.getModule(dep)),
request: dep.request,
strict: /** @type {BuildMeta} */ (module.buildMeta).strictHarmonyModule,
message: "import()",
runtimeRequirements
});
source.replace(dep.range[0], dep.range[1] - 1, content);
}
|
I don't think we need |
IIUC,
Based on above, if we stop |
Hm, intresting, it seemed to me that we do nothing in this case if the module is external, can you check it? |
Not sure what should I check, I created a online demo to show how The methods to deal with the
|
Is there any other information I can provide to help now? 👀 |
@fi3ework What about this? Now we keep |
d046b17
to
bf479bb
Compare
Thanks for the kind response and code update. I wrongly mixed the mission of
As for wiping out the extra runtime for I'll update this PR later. |
PR updated and documentation update alongside (webpack/webpack.js.org#7345). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, I think we can use this value as default (https://github.com/webpack/webpack/blob/main/lib/config/defaults.js#L271) when ES modules enabled, because modules are experemental we can change the value, I think this is more semantically correct and also reduces loading time avoiding initial loading, what do you think?
Also looks like we need to fix one our test with |
I changed the default value. Agreed that the
Fixed 😄. |
Let's update snapshot 😄 |
I've created an issue to document this in webpack/webpack.js.org. |
Thank you |
@alexander-akait We implement "module-import", but the premise is that we're using The possible options we may want to fall back to:
Here are some possible ways to adding the fallback:
Personally, I would choose Plan 1. What do you think, I could make a quick fix before next version releasing if the fallback is confirmed. |
@fi3ework hm, yeah, I see it, let's try to use |
What kind of change does this PR introduce?
Resolve #17986.
Documentation update: webpack/webpack.js.org#7345.
Following content maybe somehow out of context. This PR's final implementation is to resolve #17986.
A new external type has been introduced, mainly for the purpose of output clean artifact during bundling library. The name of this
"module-import"
is referenced from #17986 (comment), but I'm not sure if the current implementation fully meets the intention of this comment. This PR is an incomplete implementation, only implementing the handling of external processing for dynamic imports.Here's what it does:
Given following config:
source
output
There is a slightly hacky bit here, where we're deleting
ImportDependency
atfinishModules
stage to prevent any runtime code from being generated. But I couldn't find a better way to preventImportDependencyTemplate
from modifying the runtime code. Possibly by introducing a newDependencyLibraryTemplate
specifically for library patterns could achieve that. Do you have any suggestions on how to suppress runtime code generation? @alexander-akaitDid 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?
The PR is still in draft mode, it should add update the document before merged.