`new URL(foo, import.meta.url)` doesn't work when dependency was optimized
Describe the bug
Now, i use wasm-pack for build WASM file and WASM with JavaScript glue layer like this。
The glue layer code contains below code
if (typeof input === 'undefined') {
165 | input = new URL('color_thief_wasm_bg.wasm', import.meta.url);
166 | }
In Vite, after esbuild optimize third party, import.meta.url cannot be optimize succeed.
Ref Vite Docs, even if set build.target to es2020 is still the problem
After preprocess
node_modules/color-thief-wasm-web/color_thief_wasm.js will be transform to node_modules/.vite/deps/color_thief_wasm.js which load .wasm file by import.meta.url receive incorrect path is node_modules/.vite/deps/xxx.wasm finally, the correct path is node_modules/color-thief-wasm-web/xxx.wasm
One of the solutions is set optimizeDeps.exclude to exclude third party module like this
Reproduction
https://stackblitz.com/edit/vite-rkrfzu?file=src%2FApp.vue,vite.config.js
System Info
[email protected]
Used Package Manager
npm
Logs
Failed to construct 'URL': Invalid URL
Validations
- [X] Follow our Code of Conduct
- [X] Read the Contributing Guidelines.
- [X] Read the docs.
- [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
- [X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/core instead.
- [X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
- [X] The provided reproduction is a minimal reproducible example of the bug.
optimizeDeps.exclude workaround works when just starting vite. But not for vite build unfortunately, the wasm file gets excluded. Was there another workaround for the build side?
An ugly practice is move wasm package to current project rather than node_modules for get correct path
For my test, with vite build is succeed with exclude wasm package, vite will copy .wasm file to dist

I updated some of my npm packages to a later version and it copied the wasm file for me too on build. 😸 Thank goodness for that.
@yyx990803 @patak-dev When you plan to resolve the issue?
Is this the same issue on esbuild?
- https://github.com/evanw/esbuild/issues/1492
In short: import.meta.url is not transformed so, when modules are bundled into a single location, the expected .url has changed.
Input
// file at ./foo/bar.js
export default import.meta.url; // should be /full/foo/bar.js
// file at ./index.js
import url from './foo/bar.js';
console.log(url); // should still be /full/foo/bar.js
Output
// file at ./dist/index.js
const barDefaultExport = import.meta.url;
console.log(barDefaultExport);
which prints full/dist/index.js instead of /full/dist/foo/bar.js
Confirming that I have this problem with importing https://github.com/rive-app/rive-wasm. They also import their wasm file from unpkg which might also be another curve ball. I tried the workaround above with optimizeDeps.exclude but still don't see he wasm file show up in in watch/dev only build
Leaving some notes about the current status of this issue.
- I once tried to implement this but didn't finish it. I have other things that has more priority now. But I pushed the changes to #13501 for anyone who is going to implement this one.
- The issue of esbuild for the support for
import.meta.urlis https://github.com/evanw/esbuild/issues/1492- There's two PRs that implement this: https://github.com/evanw/esbuild/pull/2470, https://github.com/evanw/esbuild/pull/2508
Got a similar issue:
const template = new URL('./some.txt', import.meta.url)
return readFileSync(template, 'utf-8')
Results in
const s = new URL("data:text/plain;base64,...", self.location);
return g(s, "utf-8");
With the error self is not defined.
We just ran into this issue where we convert absolute paths into relative ones for consistent snapshots in Vitest. for anyone interested, you can use this hack to mimic the transform with the following setup code:
// correctly resolve assets referenced in optimized dependencies
// https://github.com/vitejs/vite/issues/8427
const transformUrlBase = (base?: string): typeof base => {
const { config } = (globalThis as any).__vitest_worker__;
const cacheFileUrl = pathToFileURL(
path.join(config.root, config.deps.cacheDir),
);
if (base?.toString().startsWith(cacheFileUrl.href)) {
return new URL('/@fs/node_modules/', location.href).href;
}
return base;
};
const URL = globalThis.URL;
globalThis.URL = class VitestURL extends URL {
constructor(url: string, base?: string) {
super(url, transformUrlBase(base));
}
} as typeof URL;
I am trying to import wasm from argon2d package, but even if I set:
optimizeDeps: {
exclude: ["argon2id"],
}
I still get:
[vite] Internal server error: Failed to parse source for import analysis because the content contains invalid JS syntax. You may need to install appropriate plugins to handle the .wasm?url= file format, or if it's an asset, add "**/*.wasm?url=" to `assetsInclude` in your configuration.
Plugin: vite:import-analysis
OK, adding assetsInclude: ["**/argon2id/dist/*.wasm"] worked.
I just ran in to this myself, with a deeply transitive library trying to use WASM
Hopefully this will be fixed soon, this issue is unique to Vite and doesn't happen with more modern bundler like Rsbuild.
@tien
I doubt they'll fix it soon, as they're transitioning entirely to rolldown instead of using esbuild + rollup like Vite currently does. Could you share your experience with rsbuild, along with your configuration and any necessary changes?
is that the vite 6 beta that uses rolldown?
I think so https://github.com/rolldown/vite/pull/43
I mean, I assume the transition to rolldown will force this bug to be fixed :p
Cuz this bug, if still happen will happen to both dev + prod.
Probably not the right place for this, but the transition to Rsbuild was great, faster, no bug and sometime less plugin/setup required.
@tien I think the solution might be to remove it from your optimizeDeps, but this could just be a workaround.
Linking the issue in rolldown-vite repo: https://github.com/vitejs/rolldown-vite/issues/362