evanw
commented
3 years ago This is a good suggestion. It matches with some of my thinking for some other improvements I'm planning for CSS as well. AST manipulation plugins are problematic because they require synchronous access to the AST while macro-style plugins like this involve less communication traffic and are easier to parallelize.
I don't think I understand what data is represented by the path in your example. It might be sufficient to just provide the AST as a string containing the source code for the import() expression itself and let the plugin take it from there. That avoids having to specify an AST format and is also more efficient to communicate.
Perhaps something like this:
build.onDynamicImport({ ...some filtering options TBD... }, args => {
args.expression; // The raw source code of the import() expression
args.importer; // The path of the importing file
args.namespace; // The namespace of the importing file
args.resolveDir; // The resolve directory of the importing file
return {
contents, // A module whose default export is the function to call to implement the dynamic import
};
});So you might do something like this (using the acorn parser for the sake of example):
build.onDynamicImport({}, args => {
const ast = acorn.parseExpressionAt(args.expression, 0, {ecmaVersion: 2020})
assert.strictEqual(ast.type, 'ImportExpression');
const contents = `
export default async (source) => {
${/* do something with ast.source */}
}
`
return { contents }
});This should be future-proof for import() potentially taking multiple arguments if import assertions add additional syntax. And having the raw source code lets you parse out any special magic Webpack comments that your plugin may want to interpret. It's not fully general-purpose because you won't be able to handle dynamic imports that rely on the context of the surrounding code the way a normal AST-style plugin might work in other bundlers. But if you want to do that, you can always just write a custom on-load plugin instead and preprocess the whole source file.
I'm imagining that esbuild would transform something like this:
import(something).then(
result => console.log(result),
error => console.error(error),
)into something like this:
import importShim from '...auto-generated module representing the future result of calling the plugin...'
importShim(something).then(
result => console.log(result),
error => console.error(error),
)and then the plugin would be called asynchronously. The parser can finish parsing the file without waiting for the plugin. The benefit of replacing the import() expression with a direct call to the shim function instead of with another import() expression to load the shim is that it avoids a potential double round trip over the network to load a module dynamically.
arcanis
ggoodman
olee
eduardoboucas
adamdbradley
rtsao
eyelidlessness
futurebenmorris
Ritvyk
benwis
kjoedion
jcompagner
mcfdez
MarkShawn2020
krei-se
I know there have been multiple threads on the subject (#661, #453, #322, #56), but since plugins are now a thing I figured it could be worth opening one more discussion. Perhaps there could be a solution that doesn't require statically pregenerating files? At least I haven't seen my suggestion elsewhere 😄
ESBuild currently warns when it detects dynamic imports, and leaves them in-place. It's a good start, but it's not enough: whatever is tasked from consuming them will still lose critical information, in particular the location the dynamic import is relative to (for instance, when doing an
import('./widgets/' + name)into an application compiled via--bundle, I really need to know where was the file that made this import).My suggestion to support dynamic imports with only a little extra API surface would be to instead yield the generation of an intermediary dynamic import module to a special type of loader. For example, the following loader would allow dynamic imports where each module would end up in their own chunk:
On the other hand, if I wanted to make a dynamic import where all modules are in the same chunk, then I'd just need my loader to generate regular
import fromstatements, without the consumer code having to know about this. I feel like this might match the kind of flexibility you had in mind given how loaders currently work.