node-rs
node-rs copied to clipboard
SvelteKit 2 & Cloudflare Page: Could not resolve "@node-rs/argon2-wasm32-wasi"
I made a project to reproduce the error here: https://github.com/Shyrogan/sveltekit-argon2-cf-error
> Using @sveltejs/adapter-cloudflare
✘ [ERROR] Could not resolve "@node-rs/argon2-wasm32-wasi"
node_modules/@node-rs/argon2/browser.js:1:14:
1 │ export * from '@node-rs/argon2-wasm32-wasi'
╵ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can mark the path "@node-rs/argon2-wasm32-wasi" as external to exclude it from the bundle, which will remove this error and leave the unresolved path in the bundle.
error during build:
Error: Bundling with esbuild failed with 1 error
at adapt (file:///Users/sebastienvial/Documents/transitions.ag/cloudflare-pages-sveltekit/node_modules/@sveltejs/adapter-cloudflare/index.js:134:11)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async adapt (file:///Users/sebastienvial/Documents/transitions.ag/cloudflare-pages-sveltekit/node_modules/@sveltejs/kit/src/core/adapt/index.js:38:2)
at async finalise (file:///Users/sebastienvial/Documents/transitions.ag/cloudflare-pages-sveltekit/node_modules/@sveltejs/kit/src/exports/vite/index.js:890:7)
at async Object.handler (file:///Users/sebastienvial/Documents/transitions.ag/cloudflare-pages-sveltekit/node_modules/@sveltejs/kit/src/exports/vite/index.js:920:5)
at async PluginDriver.hookParallel (file:///Users/sebastienvial/Documents/transitions.ag/cloudflare-pages-sveltekit/node_modules/rollup/dist/es/shared/node-entry.js:19730:17)
at async Object.close (file:///Users/sebastienvial/Documents/transitions.ag/cloudflare-pages-sveltekit/node_modules/rollup/dist/es/shared/node-entry.js:20665:13)
at async build (file:///Users/sebastienvial/Documents/transitions.ag/cloudflare-pages-sveltekit/node_modules/vite/dist/node/chunks/dep-D8YhmIY-.js:65760:17)
at async CAC.<anonymous> (file:///Users/sebastienvial/Documents/transitions.ag/cloudflare-pages-sveltekit/node_modules/vite/dist/node/cli.js:828:5)
I have the same issue with esbuild (webpack was fine) using node v22 not finding @node-rs/jieba-wasm32-wasi
if I use an older v1.19.0 version that gives a bit more info (about 'path' and then the correct bit jieba-win32-x64-msvc)
X [ERROR] Could not resolve "path"
node_modules/@node-rs/jieba/index.js:11:12:
11 │ } = require('path');
╵ ~~~~~~
The package "path" wasn't found on the file system but is built into node. Are you trying to bundle for node? You can use "platform: 'node'" to do that, which will remove this error.
X [ERROR] No loader is configured for ".node" files: node_modules/@node-rs/jieba-win32-x64-msvc/jieba.win32-x64-msvc.node
node_modules/@node-rs/jieba/index.js:104:36:
104 │ ... nativeBinding = require('@node-rs/jieba-win32-x64-msvc');
need to install @node-rs/jieba-wasm32-wasi or @node-rs/argon2-wasm32-wasi manually: npm i @node-rs/argon2-wasm32-wasi
I had tried that and didn't work, I get (on windows x64) this error. Looks like a 32bit image or something to me.... with the older 1.9.0 version it does install @node-rs/jieba-win32-x64-msvc (or linux version on our build machine) but then esbuild doesn't know how to load .node files.
> yarn add @node-rs/jieba-wasm32-wasi
error @node-rs/[email protected]: The CPU architecture "x64" is incompatible with this module.
error Found incompatible module.
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
@adumesny see https://github.com/napi-rs/node-rs/issues/792#issuecomment-1959141811 for the context
sure I can force install it locally once, but then anytime someone runs yarn it will give this error, so that is not a working option.
> yarn add @node-rs/jieba-wasm32-wasi --ignore-platform
add it, and create some other module error I will ignore, but then
> yarn
error @node-rs/[email protected]: The CPU architecture "x64" is incompatible with this module.
error Found incompatible module.
Should I just stick to v1.9.0 and figure out a way to have esbuild load .node extension, or possibly stubb this code out since we do no need to support chineese at this time but a module we use depends on it.
@Brooooooklyn thanks for the update.
and even when I force add I still get these errors, so back to square one
X [ERROR] No loader is configured for ".wasm" files: node_modules/@node-rs/jieba/node_modules/@node-rs/jieba-wasm32-wasi/jieba.wasm32-wasi.wasm?url
node_modules/@node-rs/jieba/node_modules/@node-rs/jieba-wasm32-wasi/jieba.wasi-browser.js:2:22:
2 │ import __wasmUrl from './jieba.wasm32-wasi.wasm?url';
╵ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
X [ERROR] Top-level await is not available in the configured target environment ("chrome128.0", "edge128.0", "firefox115.0", "ios17.0", "safari17.0" + 5 overrides)
node_modules/@node-rs/jieba/node_modules/@node-rs/jieba-wasm32-wasi/jieba.wasi-browser.js:12:19:
12 │ const __wasmFile = await fetch(__wasmUrl).then(res => res.arrayBuf...
╵ ~~~~~
X [ERROR] This require call is not allowed because the transitive dependency "node_modules/@node-rs/jieba/node_modules/@node-rs/jieba-wasm32-wasi/jieba.wasi-browser.js" contains a top-level await
node_modules/lunr-languages/lunr.zh.js:33:37:
33 │ module.exports = factory(require('@node-rs/jieba'));
╵ ~~~~~~~~~~~~~~~~
The file "node_modules/@node-rs/jieba/browser.js" imports the file "node_modules/@node-rs/jieba/node_modules/@node-rs/jieba-wasm32-wasi/jieba.wasi-browser.js" here:
node_modules/@node-rs/jieba/browser.js:1:14:
1 │ export * from '@node-rs/jieba-wasm32-wasi';
╵ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The top-level await in "node_modules/@node-rs/jieba/node_modules/@node-rs/jieba-wasm32-wasi/jieba.wasi-browser.js" is here:
node_modules/@node-rs/jieba/node_modules/@node-rs/jieba-wasm32-wasi/jieba.wasi-browser.js:12:19:
12 │ const __wasmFile = await fetch(__wasmUrl).then(res => res.arrayBuf...
fyi, I found a link comment online says you can use PBKDF2 instead of argon2 (but PBKDF2 is less secure?)
It also mentions a tutorial about using a custom "Argon2 Rust Worker" No idea if such a thing is a good idea. But sounded interesting to put here for others to find.
same problem
| 01:54:38.033 | ✘ [ERROR] Build failed with 1 error: |
|---|---|
| 01:54:38.033 | |
| 01:54:38.033 | ✘ [ERROR] Could not resolve "@node-rs/jsonwebtoken-wasm32-wasi" |
| 01:54:38.033 | |
| 01:54:38.033 | ../../node_modules/@node-rs/jsonwebtoken/browser.js:1:14: |
| 01:54:38.033 | 1 │ export * from '@node-rs/jsonwebtoken-wasm32-wasi' |
| 01:54:38.033 | ╵ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 01:54:38.034 | |
| 01:54:38.034 | You can mark the path "@node-rs/jsonwebtoken-wasm32-wasi" as external to exclude it from the bundle, which will remove this error. |
anyone has solved the problem?
My guess is this is not something that will be solved. At least not in the free tier of cloudflare workers.
Password hashing must be computationally expensive to be secure. Free tier must be cheap to be viable.
Unless what is 'computationally expensive' is actually not expensive to cloudflare, it's unlikely to be 'fixed' by cloudflare in the free tier.
I ended up choosing externalizing auth to a SAAS provider, that does offer a free tier for low amount of users.
I got this error while running npm run build locally, I'm using sveltekit2 and vite6.
4:34:02 PM [vite] (client) error while updating dependencies: Error: Build failed with 1 error: node_modules/@node-rs/argon2/browser.js:1:14: ERROR: Could not resolve "@node-rs/argon2-wasm32-wasi"
I solved this by adding
"compatibility_flags": ["nodejs_compat"]
To wrangler.jsonc file.
If you install @node-rs/argon2-wasm-wasi (or the other one) you'll still get an error. This issue seems to be from cloudflare's part
Or is there any reason to have the ?url? If not, can it be removed so wrangler doesn't complain?
I doubt that this issue is cloudflare specific because i have the same issues when i try to run the vite dev server in a sveltekit project while using the new "remote functions" from sveltekit. Even without that new feature i sometimes had issues, but now i always get these errors. Well there are different errors that happen. But all happen as soon as i use async/remote functions in sveltekit.
✘ [ERROR] Top-level await is not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari14" + 2 overrides)
node_modules/.pnpm/@[email protected]/node_modules/@node-rs/argon2-wasm32-wasi/argon2.wasi-browser.js:22:19:
22 │ const __wasmFile = await fetch(__wasmUrl).then((res) => res.arrayBuffer())
╵ ~~~~~
2:38:59 PM [vite] (client) error while updating dependencies:
Error: Build failed with 1 error:
node_modules/.pnpm/@[email protected]/node_modules/@node-rs/argon2-wasm32-wasi/argon2.wasi-browser.js:22:19: ERROR: Top-level await is not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari14" + 2 overrides)
at failureErrorWithLog (/home/user/svelte/wishman-v2/node_modules/.pnpm/[email protected]/node_modules/esbuild/lib/main.js:1463:15)
at /home/user/svelte/wishman-v2/node_modules/.pnpm/[email protected]/node_modules/esbuild/lib/main.js:924:25
at /home/user/svelte/wishman-v2/node_modules/.pnpm/[email protected]/node_modules/esbuild/lib/main.js:1341:9
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
Like the previous comment here states, I also had this problem completely independent of Cloudflare. I think the problem is that (especially with the new remote functions) the "client" bundle would sometimes "come across" the @node-rs/argon2 import, even though it is (at least in my case) not actually used in the client. Vite is only transforming the *.remote.ts file, and I expect that in the production bundle, any unused imports would get stripped out anyway. But that's just my theory.
In any case, I still got this error and it crashed the Vite server. To fix it, I explicitly added the dependency to the optimizeDeps.exclude option in vite.config.ts:
export default defineConfig({
optimizeDeps: {
exclude: ["@node-rs/argon2"],
},
// rest of your config ...
}
This resolved my problem and I was able to get back to work. I hope this helps someone else if you stumble across this issue! Again, I'm not using Cloudflare, so if there is some other problem there, I'm sorry!
@danieldiekmeier Hm...i didn't use it in remote functions. Previously i had a Password helper class in a auth module that imported @node-rs/argon2. As soon as i removed this helper class and used the hash/verify methods directly in my form actions, it worked without issues.
I'm having the same problem:
X [ERROR] Could not resolve "@node-rs/argon2-wasm32-wasi"
node_modules/@node-rs/argon2/browser.js:1:14:
1 │ export * from '@node-rs/argon2-wasm32-wasi'
╵ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can mark the path "@node-rs/argon2-wasm32-wasi" as external to exclude it from the bundle, which will remove this error and leave the unresolved path in the bundle.
No idea how to fix it. I'm using adapter-node and when I build it works fine. But npm run dev flags this error :(