Dynamic import hook - #1790

It is worth also mentioning that this work is effectively flagged, as it requires the acorn: { plugins: { dynamicImport: true } } option to apply at all.

Hi @guybedford. Just note I am a little short on time working on rollup at the moment so reviewing this will take a few days, nevertheless thanks for all the effort you are putting in at the moment, I'll be in touch shortly.

@lukastaegert thanks for the update! No worries, when you are ready, and thanks for taking the time.

How does inlining behave exactly? Assume the following:

// a.js
console.log('destroy the world');

// b.js
document.addEventListener('click', () => {
  import('./a');
});

If inlining hoists importing of internal module ./a, then destroy the world will be logged unconditionally although that's not what we want.

Or does inlining work if and only if ./a was imported and included in the bundle by synchronous import statements? If that's the case, I'm assuming we'll need to have a separate bundling step for all files whose entry file is ./a. Assume the following:

// a.js
import { hugeFunction } from './c';
console.log(hugeFunction('destroy the world'));

// b.js
import { hugeFunction } from './c';
hugeFunction('foo');
document.addEventListener('click', () => {
  import('./a');
});

// c.js
console.log('a side effect');
export function hugeFunction(x) { /* a huge impl */ }

$ rollup src/a.js && rollup src/b.js

And in this scenario, hugeFunction and side-effects inside ./c are duplicated between bundles.

I'm sketching out some drawbacks/misconceptions rollup users may have using async imports so a relevant documentation can be updated accordingly.

@anilanar you've got the interpretations exactly right here in the second example - inlining only happens when the module is already included statically in the build. As for the use cases around dynamic import, some different thinking is needed to make these work out. I hope to share my project for handling deduplication along these lines next week!

Note one other optimization that could be added would be to use static analysis to trace which exports are used by the dynamic imported form.

For example:

import {b} from 'x';
import('x').then(x => {
  x.a();
});

Could know that we only use a and b from "x" and not all the other exports. That is, the inlining case should be able to apply tree shaking. And in the non-inlining case we should at least be able to return some metadata with the bundle informing which exports are used of the dynamic imports when we can deduce this (and being clear when we can't).

Happy to move in these sort of directions in due course with further PRs as well.

Thanks @lukastaegert for the feedback here, I'm really glad to hear that API sounds sensible to you.

An experimental flag would be good for this - I've added this as options.experimentalDynamicImport.

I was just going to say actually I might have an alternative approach here....

@lukastaegert can you DM me on twitter?

+1 👏

Actually I kinda messed up this merge anyway because I overlooked some issues with another PR and think I might start assembling the release from scratch tomorrow. So no harm done, I can leave out this PR if you have got a better idea.

It’s kinda late today but we can talk tomorrow

Sure, happy to merge this as-is. I realise now what I was thinking is along the lines of a default dynamicImport hook, which fits into how all the hooks work, so there are no conflicts of direction.

But it would be good to chat about some of this some more at some point if you have a moment, as I've found it's easier to build this sort of tooling when being able to hook into Rollup through the Bundle API over the rollup.rollup API.