new URL(foo, import.meta.url) doesn't work when dependency was optimized

[zhangyuang]

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

vite@2.9.9

Used Package Manager

npm

Logs

Failed to construct 'URL': Invalid URL

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• 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.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[clinuxrulz]

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?

[zhangyuang]

An ugly practice is move wasm package to current project rather than node_modules for get correct path

[zhangyuang]

For my test, with vite build is succeed with exclude wasm package, vite will copy .wasm file to dist

[clinuxrulz]

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.

[fregante]

Is this the same issue on esbuild?

• import.meta.url support evanw/esbuild#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

[zltn]

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

[sapphi-red]

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 feat(optimizer): support import.meta.url #13501 for anyone who is going to implement this one.
• The issue of esbuild for the support for import.meta.url is import.meta.url support evanw/esbuild#1492
  • There's two PRs that implement this: Include new URL("...", import.meta.url) references in the import graph. evanw/esbuild#2470, Batch of several breaking changes evanw/esbuild#2508

[susnux]

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.

[kherock]

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;

[NullVoxPopuli]

I just ran in to this myself, with a deeply transitive library trying to use WASM

[tien]

Hopefully this will be fixed soon, this issue is unique to Vite and doesn't happen with more modern bundler like Rsbuild.

[sedghi]

@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?

[NullVoxPopuli]

is that the vite 6 beta that uses rolldown?

[sedghi]

I think so rolldown#43

[tien]

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.

[sedghi]

@tien I think the solution might be to remove it from your optimizeDeps, but this could just be a workaround.