Treeshaking before resolving dynamic imports

[larsrh]

Feature Use Case

Currently, Rollup chases imports eagerly. However, if a dynamic import is located in a function that later gets shaken out, it was "all for nothing". Rollup could chase dynamic imports lazily until it is sure that they'll be included in the bundled output.

Feature Proposal

Source file:

function foo() {
  return import("non-existing-package");
}

export function bar() {
  return 3;
}

Current Rollup output:

$ npx rollup dynamic.js 
dynamic.js → stdout...
function bar() {
  return 3;
}

export { bar };
(!) Unresolved dependencies
https://rollupjs.org/guide/en/#warning-treating-module-as-external-dependency
non-existing-package (imported by dynamic.js)

Desired output: (same, but without the warning)

This could be helpful when building packages with different entrypoints for universal, Node-specific, and browser-specific code.

[seivan]

I like the idea but it depends on implementation complexity and trade offs. The only negative I see as of now, is that you just get a bundle outputted, as in it doesn't impact your actual runtime. If adding a fix for this causes bigger headaches it's not worth it.

A counter point would be that you actually want the chunk to be made, but your current code that uses the chunk is tree shaken. But it doesn't mean you won't load it at runtime in some other way.

Sorry for butting in!