initialize() being called in a different directory confuses native import() in supported browsers

[rdmurphy]

Hello! 👋

I've been working on adding this polyfill to our builds but surprisingly it has caused issues in our browsers that do support native dynamic import()!

I have a rollup build that manages our multiple inputs and outputs shared chunks into a chunks directory — something like this:

scripts/
  entry-one.js
  entry-two.js
  chunks/
    dynamic-import-polyfill.js
    another-shared-chunk.js

Because both entries import dynamic-import-polyfill, it gets code split into its own file that each entry statically imports.

But what I've found is that this line seemingly tricks native import() into always thinking its "root" is always that chunks directory and it fails to resolve any future dynamic imports that aren't relative to that.

I don't know if it's necessarily a bug that can be "fixed" but it may be worth at a minimum noting in the documentation that the polyfill should be loaded at the same directory level as your main script or else it'll cause issues. But I also have no clue if this manifests in other ways as well. 😬 (Like, what happens if this "native" dynamic import tries to load a file one directory up?) It was a real shock that native dynamic import started acting differently as a result of adding this, though!

Thank you!

[philipwalton]

I do kinda mention this in the Limitations section of the README, but perhaps it wasn't clear that "same directory" also precludes sub-directories.

I'm curious to see your setup though, and maybe I can get the polyfill working with it. Do you have a link to a repo somewhere? Also, I'm curious why you've chosen to output your chunks into a separate directory. Could you accomplish the same with a chunk- prefix (or something like that)?

[rdmurphy]

Hah, fair! I saw that section mentioned import.meta and went "ah, no worries not using that" but I see how it suggests this is a limitation.

I did try using a prefix for the chunks instead and it did work. I'll try to throw together a tiny reproduction (my current example is right in the thick of another mess in a private repo). I don't have a good reason for putting them in a directory, really. 😅 Mainly an organizational choice.

What I was wishing I could do was force Rollup to not code-split just this import but I don't believe it's possible yet.

[rdmurphy]

All right! I've recreated it in a fork of your rollup-native-modules-boilerplate repo.

You'll see it happening when it tries to perform a dynamic import of journalize from the entry point after the polyfill is initialized.