Skip to content

Conversation

@Brooooooklyn
Copy link
Member

No description provided.

Copy link
Member Author

This stack of pull requests is managed by Graphite. Learn more about stacking.

},
// Suppress the warning: The file does not exist at "oxc-playground/node_modules/.vite/deps/@oxc-parser/binding-wasm32-wasi/wasi-worker-browser.mjs?worker_file&type=module" which is in the optimize deps directory. The dependency might be incompatible with the dep optimizer. Try adding it to `optimizeDeps.exclude`.
// Need to resolve
exclude: ['@oxc-parser/binding-wasm32-wasi'],
Copy link
Member Author

@Brooooooklyn Brooooooklyn Mar 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't know why need this, it works fine in NAPI-RS playground: https://github.com/napi-rs/node-rs-playground/blob/main/vite.config.ts

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the difference is that node-rs-playground example doesn't use worker, so it doesn't hit the code new Worker(new URL(..., import.meta.url)), but parseAsync uses a worker. Unfortunately, Vite's optimizer (esbuild) doesn't support new URL rewriting etc..., so Vite dev requires dependencies with new URL(...) and alike to be specified in optimizeDeps.exclude vitejs/vite#8427

Side note: Contrary to what I thought, I just realized ?url is supported by Vite optimized deps, so changing that into new URL napi-rs/napi-rs#2511 can affect non-worker use case, which didn't require optimizeDeps.exclude workaround 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, actually optimizeDeps.exclude is not necessary if @oxc-parser/binding-wasm32-wasi is explicitly installed locally as project dependency. This is probably because wasi-browser.js has new URL("@oxc-parser/binding-wasm32-wasi/wasi-worker-browser.mjs", import.meta.url), so Vite can resolve it properly as long as @oxc-parser/binding-wasm32-wasi is visible from project node_modules.

node-rs-playground uses yarn's flat node_modules, so node_modules/@oxc-parser/binding-wasm32-wasi is visible even if it's installed as optional architecture dep.

@Boshen
Copy link
Member

Boshen commented Mar 8, 2025

This is just an experiment, I'll do the rest of the heavy lifting.

Copy link
Contributor

@hi-ogawa hi-ogawa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! I didn't know you guys are experimenting it here.

},
// Suppress the warning: The file does not exist at "oxc-playground/node_modules/.vite/deps/@oxc-parser/binding-wasm32-wasi/wasi-worker-browser.mjs?worker_file&type=module" which is in the optimize deps directory. The dependency might be incompatible with the dep optimizer. Try adding it to `optimizeDeps.exclude`.
// Need to resolve
exclude: ['@oxc-parser/binding-wasm32-wasi'],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the difference is that node-rs-playground example doesn't use worker, so it doesn't hit the code new Worker(new URL(..., import.meta.url)), but parseAsync uses a worker. Unfortunately, Vite's optimizer (esbuild) doesn't support new URL rewriting etc..., so Vite dev requires dependencies with new URL(...) and alike to be specified in optimizeDeps.exclude vitejs/vite#8427

Side note: Contrary to what I thought, I just realized ?url is supported by Vite optimized deps, so changing that into new URL napi-rs/napi-rs#2511 can affect non-worker use case, which didn't require optimizeDeps.exclude workaround 🤔

@Boshen Boshen closed this Mar 17, 2025
@Boshen Boshen deleted the 03-08-refactor_use_oxc-parser_directly branch March 17, 2025 15:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants