Dynamic import not working as expected with base public path option. about vite HOT 5 CLOSED

Start a new pull request in StackBlitz Codeflow.

• vitejs-vite-bdc46m (Open reproduction)

from vite.

import("./dynamic-HASH.js"); is relative to the file containing that statement. As long as you are serving the file importing the other file and the imported file on the same origin, it won't be an issue.

from vite.

The problem is the imported file is not on the same origin.
For example, I am hosting my library at www.someWebsite.com/main.js, and the imported file is at www.someWebsite.com/dynamic-HASH.js.

If the library is consumed via www.anotherWebsite.com, this is a different origin, so the import("./dynamic-HASH.js"); would fail, as it would try to grab it from www.anotherWebsite.com/dynamic-HASH.js.

from vite.

Do you have the file importing dynamic-HASH.js on a different origin from dynamic-HASH.js? For example, www.someWebsite.com/main.js imports www.anotherWebsite.com/dynamic-HASH.js.
In that case, you should make dynamic-HASH.js an entry point instead of a implicit chunk generated by dynamic import, otherwise the entry signature can be changed by rollup (some export might be removed if main.js doesn't use it).

If you have main.js and dynamic-HASH.js served on the same origin and importing main.js from a different origin, then import can work with relative path. It will be resolved from main.js and not the location.href/document.baseURI.

from vite.

If you have main.js and dynamic-HASH.js served on the same origin and importing main.js from a different origin, then import can work with relative path. It will be resolved from main.js and not the location.href/document.baseURI.

Interesting, you are correct, I tested this and this does seem to be the case. I vaguely remember I had problems with webpack around a similar issue (maybe it handles dynamic imports differently?), so that might be why I assumed the latter to be true.

Thanks for the help/clarification!

from vite.