How to import a method from a module statically and another method from the same module dynamically ?

[imagoiq]

Hi,

I would love to be able to optimize polyfill loading, but I can't find a proper way. Here is the idea, import isSupported to check if the polyfill is needed and import dynamically the apply function only when needed.

import { isSupported } from "invokers-polyfill/fn";

void (async () => {
  // HTML Invokers Polyfill

  if (!isSupported) {
    const { apply } = await import("invokers-polyfill/fn");
    apply();
  }
})();

With this code, I'm getting the following warning on build, and all code appears in the same file:

✓ 3 modules transformed.
[plugin vite:reporter] 
(!) /project/workspace/node_modules/.pnpm/invokers-polyfill@1.0.1/node_modules/invokers-polyfill/invoker.js is dynamically imported by /project/workspace/polyfill.js but also statically imported by /project/workspace/polyfill.js, dynamic import will not move module into another chunk.

dist/assets/polyfill-BcPiOrKD.js  6.82 kB │ gzip: 2.57 kB

You can check with this demo and running npm run build: https://codesandbox.io/p/devbox/9zg3qm

Using a "re-export workaround" hides the warning but doesn't create another chunk for the dynamic import: https://codesandbox.io/p/devbox/vite-polyfill-dynamic-import-will-not-move-into-another-chunk-with-re-export-workaround-h8l733

Note that it happens with other polyfill like https://github.com/oddbird/popover-polyfill (but it's probably using the same structure)

Is there a way? Is there an issue with those modules? What am I missing?

Related links ?:

• Treeshake "static" dynamic import rollup/rollup#4951
• Warn when a dynamically imported chunk is statically imported #12706
• Dynamic imports are not tree-shaken #11080
• Vite not tree-shaking dynamic imports #14145
• https://medium.com/@christiango/the-unexpected-impact-of-dynamic-imports-on-tree-shaking-ddadeb135dd7
• https://rollupjs.org/tutorial/#code-splitting

[RayverAimar]

Hey! I ran into something similar before. This is basically a Rollup limitation — if a module is statically and dynamically imported from the same file, Rollup just won't split it into a separate chunk. The static import already pulls it into the bundle so the dynamic import() becomes a no-op in terms of code splitting.

What worked for me was splitting the imports into separate wrapper files so Rollup sees them as different entry points:

// polyfill-check.js
export { isSupported } from "invokers-polyfill/fn";

// polyfill-apply.js
export { apply } from "invokers-polyfill/fn";

// polyfill.js
import { isSupported } from "./polyfill-check";

void (async () => {
  if (!isSupported) {
    const { apply } = await import("./polyfill-apply");
    apply();
  }
})();

Your re-export workaround probably didn't work because Rollup still traces both imports back to the same source module. With separate files it actually sees two different entry points and splits them into chunks.

Related: rollup/rollup#4951

[imagoiq]

Thanks. I've tried here https://codesandbox.io/p/devbox/vite-polyfill-dynamic-import-will-not-move-into-another-chunk-with-re-export-workaround-forked-wcjwpl?workspaceId=ws_SohSVZzbWrDK5D8vU7Zh1F

It seems to work, but only if I specify polyfill-check.js and polyfill-apply.js into the vite.config rollupOptions input.

[aniruddhaadak80]

Hi @imagoiq!

Vite is usually blazingly fast, but issues like this often crop up around dependency pre-bundling or rollup configurations.

1. Pre-bundling: Try deleting your node_modules/.vite cache and running npm run dev -- --force to make Vite rebuild the dependencies.
2. Externalizing Modules: If you are seeing issues where built-in node modules (like "stream" or "path") are breaking, it is because Vite is primarily a frontend build tool. You might need to add polyfills via vite-plugin-node-polyfills or explicitly externalize it in build.rollupOptions.external.

Let me know if clearing the Vite cache or tweaking the Rollup config gets you past this hurdle.

Hope this points you in the right direction! Let me know how it goes. Happy coding!

[Shubrathshetty]

Remove the static import entirely. Since isSupported is just a feature-detection boolean, replicate that check inline yourself. Then the dynamic import is truly lazy and Rollup will split it into its own chunk.
// polyfill.js

void (async () => {
// Inline the feature detection — no static import needed.
// This mirrors what invokers-polyfill's isSupported actually checks.
const isSupported =
"invokeAction" in HTMLButtonElement.prototype ||
"commandForElement" in HTMLButtonElement.prototype;

if (!isSupported) {
// Now this is a GENUINE dynamic import with no static counterpart.
// Rollup/Vite will correctly split this into a separate chunk.
const { apply } = await import("invokers-polyfill/fn");
apply();
}
})();
After this change your build output should look like:
dist/assets/polyfill-BcPiOrKD.js 0.3 kB ← tiny entry (just the check)
dist/assets/invokers-chunk-XyZ123.js 6.5 kB ← only loaded when needed

[imagoiq]

For sure, but it is a workaround. What if the polyfill isSupported change? You won't get notified of this change. This happened recently for this other polyfill for example: tak-dcxi/dialog-closedby-polyfill#14

[travisbreaks]

This is a fundamental constraint in Rollup's chunking algorithm (inherited by Vite). When a module is both statically and dynamically imported from the same file, the static import wins: the module gets pulled into the importer's chunk, and the dynamic import() resolves synchronously from there. No separate chunk is created.

The wrapper-file approach mentioned above works, but you shouldn't need rollupOptions.input for it. The key is that the wrapper must only be dynamically imported, never statically imported anywhere in the graph. If any file statically imports it, Rollup merges it back.

Here's the cleanest pattern for conditional polyfills:

// polyfill.js
void (async () => {
  const { isSupported } = await import("invokers-polyfill/fn");
  if (!isSupported) {
    const { apply } = await import("invokers-polyfill/fn");
    apply();
  }
})();

Both imports are dynamic, so Rollup can split invokers-polyfill/fn into its own chunk. The cost: isSupported is no longer available synchronously. But for a polyfill guard that runs once at startup inside an async IIFE, that's fine.

If you need the check to be synchronous (zero network cost when the feature is supported), split them into two distinct modules so Rollup sees no overlap:

// detect.js -- only exports the boolean
export { isSupported } from "invokers-polyfill/fn";

// polyfill.js
import { isSupported } from "./detect.js";

if (!isSupported) {
  const { apply } = await import("invokers-polyfill/fn");
  apply();
}

This works without touching rollupOptions.input because detect.js re-exports only isSupported, which is a tiny boolean check. Rollup will inline it into the main chunk (that's fine, it's small). The heavy apply code only loads when needed via the dynamic import, which Rollup correctly splits into a separate chunk because invokers-polyfill/fn is no longer statically imported from polyfill.js directly.

The reason your earlier re-export workaround didn't split: Rollup traces through re-exports and sees the same underlying module ID on both the static and dynamic sides. The detect.js wrapper works because the static import graph only touches isSupported through detect.js, and the dynamic import pulls invokers-polyfill/fn directly. Rollup treats these as separate resolution paths.

Why rollupOptions.input "fixed" the other approach: Adding a file to input makes it an entry point with its own chunk. That's a sledgehammer. You don't want to manage polyfill files as explicit entry points.

[imagoiq]

Thanks for the detailed explanation. I've tried in my existing example of the first post, but with changing the naming to match your example: https://codesandbox.io/p/devbox/vite-polyfill-dynamic-import-will-not-move-into-another-chunk-with-re-export-workaround-h8l733?file=%2Fpolyfill.js%3A3%2C20

Here is the result:

✓ 4 modules transformed.
[plugin vite:reporter] 
(!) /project/workspace/node_modules/.pnpm/invokers-polyfill@1.0.1/node_modules/invokers-polyfill/invoker.js is dynamically imported by /project/workspace/polyfill.js but also statically imported by /project/workspace/detect.js, dynamic import will not move module into another chunk.

dist/assets/polyfill-BcPiOrKD.js  6.82 kB │ gzip: 2.57 kB

Am I missing something? I kept the IIFE as I'll need it to support older browsers.