Could not resolve "@node-rs/argon2-wasm32-wasi"

[danestves]

Getting the following error when using oslo with vite

[pilcrowonpaper]

What package manager are you using?

[pilcrowonpaper]

Also, are you using a pure Vite setup, or using some kind of framework? What OS are you using?

[danestves]

Using bun, here is the full output, my current setup is Vite + Remix (with vite plugin):

  System:
    OS: macOS 14.2.1
    CPU: (8) arm64 Apple M1 Pro
    Memory: 241.36 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.10.0 - ~/.nvm/versions/node/v20.10.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v20.10.0/bin/yarn
    npm: 10.2.3 - ~/.nvm/versions/node/v20.10.0/bin/npm
    pnpm: 8.9.0 - ~/.nvm/versions/node/v20.10.0/bin/pnpm
    bun: 1.0.25 - /opt/homebrew/bin/bun
  Browsers:
    Chrome: 121.0.6167.85
    Safari: 17.2.1
  npmPackages:
    @biomejs/biome: 1.5.3-nightly.24fcf19 => 1.5.3-nightly.24fcf19
    @conform-to/react: 1.0.0-rc.1 => 1.0.0-rc.1
    @conform-to/zod: 1.0.0-rc.1 => 1.0.0-rc.1
    @epic-web/cachified: 4.0.0 => 4.0.0
    @epic-web/client-hints: 1.2.2 => 1.2.2
    @epic-web/invariant: 1.0.0 => 1.0.0
    @epic-web/remember: 1.0.2 => 1.0.2
    @hono/node-server: 1.5.0 => 1.5.0
    @hono/sentry: 1.0.0 => 1.0.0
    @hono/vite-dev-server: 0.4.1 => 0.4.1
    @iconify-json/logos: 1.1.42 => 1.1.42
    @lemonsqueezy/lemonsqueezy.js: 1.2.5 => 1.2.5
    @nasa-gcn/remix-seo: 2.0.0 => 2.0.0
    @paralleldrive/cuid2: 2.2.2 => 2.2.2
    @prisma/client: 5.8.1 => 5.8.1
    @react-email/components: 0.0.14 => 0.0.14
    @remix-run/dev: 2.5.1 => 2.5.1
    @remix-run/node: 2.5.1 => 2.5.1
    @remix-run/react: 2.5.1 => 2.5.1
    @remix-run/serve: 2.5.1 => 2.5.1
    @sentry/profiling-node: 1.3.5 => 1.3.5
    @sentry/remix: 7.98.0 => 7.98.0
    @sumup/intl: 1.6.0 => 1.6.0
    @svgr/core: 8.1.0 => 8.1.0
    @svgr/plugin-jsx: 8.1.0 => 8.1.0
    @total-typescript/ts-reset: 0.5.1 => 0.5.1
    @trigger.dev/react: 2.3.16 => 2.3.16
    @trigger.dev/remix: 2.3.16 => 2.3.16
    @trigger.dev/sdk: 2.3.16 => 2.3.16
    @types/cookie: 0.6.0 => 0.6.0
    @types/fs-extra: 11.0.4 => 11.0.4
    @types/glob: 8.1.0 => 8.1.0
    @types/node: 20.11.10 => 20.11.10
    @types/react: 18.2.48 => 18.2.48
    @types/react-dom: 18.2.18 => 18.2.18
    @types/source-map-support: 0.5.10 => 0.5.10
    @unpic/react: 0.1.8 => 0.1.8
    @upstash/ratelimit: 1.0.0 => v1.0.0
    @zenstackhq/runtime: 1.7.1 => 1.7.1
    autoprefixer: 10.4.17 => 10.4.17
    buffer: 6.0.3 => 6.0.3
    chalk: 5.3.0 => 5.3.0
    close-with-grace: 1.2.0 => 1.2.0
    concurrently: 8.2.2 => 8.2.2
    cookie: 0.6.0 => 0.6.0
    cross-env: 7.0.3 => 7.0.3
    crypto-js: 4.2.0 => 4.2.0
    cva: 1.0.0-beta.1 => 1.0.0-beta.1
    date-fns: 3.3.1 => 3.3.1
    dotenv: 16.4.1 => 16.4.1
    esbuild: 0.20.0 => 0.20.0
    fs-extra: 11.2.0 => 11.2.0
    get-port: 7.0.0 => 7.0.0
    glob: 10.3.10 => 10.3.10
    hono: 3.12.8 => 3.12.8
    husky: 9.0.6 => 9.0.6
    i18next: 23.8.0 => 23.8.0
    i18next-browser-languagedetector: 7.2.0 => 7.2.0
    i18next-fs-backend: 2.3.1 => 2.3.1
    i18next-http-backend: 2.4.2 => 2.4.2
    intl-parse-accept-language: 1.0.0 => 1.0.0
    is-ci: 3.0.1 => 3.0.1
    is-ip: 5.0.1 => 5.0.1
    isbot: 4.4.0 => 4.4.0
    lint-staged: 15.2.0 => 15.2.0
    motion: 10.17.0 => 10.17.0
    oslo: 1.0.2 => 1.0.2
    postgres: 3.4.3 => 3.4.3
    posthog-js: 1.103.1 => 1.103.1
    posthog-node: 3.6.1 => 3.6.1
    prisma: 5.8.1 => 5.8.1
    react: 18.3.0-canary-feed8f3f9-20240118 => 18.3.0-canary-6639ed3b3-20240111
    react-aria-components: 1.0.1 => 1.0.1
    react-dom: 18.3.0-canary-feed8f3f9-20240118 => 18.3.0-canary-6639ed3b3-20240111
    react-email: 2.0.0 => 2.0.0
    react-i18next: 14.0.1 => 14.0.1
    react-number-format: 5.3.1 => 5.3.1
    react-otp-input: 3.1.1 => 3.1.1
    react-twc: 1.4.1 => 1.4.1
    remix-auth: 3.6.0 => 3.6.0
    remix-auth-google: 2.0.0 => 2.0.0
    remix-development-tools: 3.7.4 => 3.7.4
    remix-flat-routes: 0.6.4 => 0.6.4
    remix-hono: 0.0.15 => 0.0.15
    remix-i18next: 5.5.0 => 5.5.0
    remix-routes: 1.6.1 => 1.6.1
    remix-utils: 7.5.0 => 7.5.0
    resend: 3.1.0 => 3.1.0
    source-map-support: 0.5.21 => 0.5.21
    spin-delay: 1.2.0 => 1.2.0
    svix: 1.16.0 => 1.16.0
    tailwind-merge: 2.2.1 => 2.2.1
    tailwindcss: 3.4.1 => 3.4.1
    tailwindcss-animate: 1.0.7 => 1.0.7
    tailwindcss-aria-attributes: 2.0.1 => 2.0.1
    tailwindcss-react-aria-components: 1.0.0 => 1.0.0
    tsx: 4.7.0 => 4.7.0
    typescript: 5.3.3 => 5.3.3
    typescript-remix-routes-plugin: 1.0.1 => 1.0.1
    unique-username-generator: 1.3.0 => 1.3.0
    unplugin-icons: 0.18.3 => 0.18.3
    vite: 5.0.12 => 5.0.12
    vite-tsconfig-paths: 4.3.1 => 4.3.1
    zenstack: 1.7.1 => 1.7.1
    zod: 3.22.4 => 3.22.4

[pilcrowonpaper]

Yeah the issue seems that for some reason Vite is trying to use the WASM/browser version instead of native bindings

[pilcrowonpaper]

Does npm run build also cause an error?

[pilcrowonpaper]

For me, build works fine. It seems that Vite optimizes dependencies on dev which leads to a different behavior than build. My guess is that Vite sees the browser field in both node-rs packages, and picks that but only for dev.

[pilcrowonpaper]

The solution for now is to disable optimization but I feel like this is a bug on Vite's end?

{
  optimizeDeps: {
    exclude: ["@node-rs/argon2", "@node-rs/bcrypt"]
  }
}

[pilcrowonpaper]

This only seems to be an issue because it's a dependency of an ESM package. It works fine when @node-rs/argon2 etc is installed and imported directly

[pilcrowonpaper]

#26 isn't a long term solution so we should probably debug this in the meantime

[pilcrowonpaper]

Nah, ok #26 didn't fix the issue. I can reproduce this issue in Astro but not SvelteKit even if they both use the same Vite version wtf

[pilcrowonpaper]

Ok for Astro, it seems it's fine if you import oslo/password into .astro files but breaks when import it into .ts API routes

[pilcrowonpaper]

Framework	Works out of the box
Astro	❌
Nuxt	✅
Remix	❌
SolidStart	✅
SvelteKit	✅
Vite raw SSR	❓

[pilcrowonpaper]

Found the issue! It's not with Vite specially. It's related to how frameworks differentiate between client and server only modules - or how they don't. Thanks to @bluwy for helping me here:

If I had to guess, I think our configuration here, is incorrectly scanning the endpoints as browser code for dependencies to be optimized. IIRC it's done so because we can't be sure where client code can be placed. But maybe we can be a little strict here because we know for sure that .js or .ts files in src/pages are not client code for sure

Usually it's not an issue since if it's not supposed to be prebundled, esbuild would just silently work and the dep was never requested anyways, but we can definitely improve this part for perf and the bug too

I've open a new issue in Astro's repo: withastro/astro#9859

[pilcrowonpaper]

The same issue is likely present in Remix

[pilcrowonpaper]

For Astro, the solution is to exclude oslo from the optimization.

// astro.config.mjs
export default defineConfig({
  // vite
  vite: {
    optimizeDeps: {
      exclude: ["oslo"]
    }
  }
});

[pilcrowonpaper]

For Remix, you'd want to re-export it from .server.ts e.g.

// auth.server.ts
export { Argon2id } from "oslo/password";

import { json } from "@remix-run/node";

import { useLoaderData } from "@remix-run/react";
import { Argon2id } from "~/auth.server";

export async function loader() {
  return json({
    hash: await new Argon2id().hash("password"),
  });
}

export default function Index() {
  const data = useLoaderData<typeof loader>();
  return <p>{data.hash}</p>;
}

If you're using Vite, use the Astro solution above.

[danestves]

I can verify that putting the optimizeDeps works like a charm, I was already using the .server files, but the other did the trick, thank you!

[dinogomez]

To anyone encountering this with NextJS, I found out that when running turbo using next dev --turbo it triggered on signing out when invalidating the cookies and creating a new blank session cookie with the signout server actions. running the default next dev sorted things out.

[igorgusarov]

I'm having this issue with Nuxt 3.11.2 + Lucia and Oslo.

In my case the issue is that I'm building the project on a Mac and deploying it on Ubuntu Server, which (I think) is expecting different builds of argon2 and bcrypt. I was able to fix this by manually installing @node-rs/argon2-linux-x64-gnu and @node-rs/bcrypt-linux-x64-gnu.

It would be nice if it was possible to build the project without additional dependencies.

[pitzzahh]

I also encountered this error. when running in dev and it crashes. However, when I build and run it no error is encountered.

✘ [ERROR] Could not resolve "@node-rs/argon2-wasm32-wasi"

    node_modules/.pnpm/@node-rs+argon2@1.8.3/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.

/home/peter/hrms/node_modules/.pnpm/esbuild@0.20.2/node_modules/esbuild/lib/main.js:1651
  let error = new Error(text);
              ^

Error: Build failed with 1 error:
node_modules/.pnpm/@node-rs+argon2@1.8.3/node_modules/@node-rs/argon2/browser.js:1:14: ERROR: Could not resolve "@node-rs/argon2-wasm32-wasi"
    at failureErrorWithLog (/home/peter/hrms/node_modules/.pnpm/esbuild@0.20.2/node_modules/esbuild/lib/main.js:1651:15)
    at /home/peter/hrms/node_modules/.pnpm/esbuild@0.20.2/node_modules/esbuild/lib/main.js:1059:25
    at /home/peter/hrms/node_modules/.pnpm/esbuild@0.20.2/node_modules/esbuild/lib/main.js:1527:9
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  errors: [Getter/Setter],
  warnings: [Getter/Setter]
}

Node.js v20.13.1
 ELIFECYCLE  Command failed with exit code 1.
 ```
 
 Framework: SvelteKit
 
 No problems on app build. Only encountered during development.

[pulgueta]

I get this issue with Next.js 14.2.3 without Turbopack and with the middleware.ts file. Has somebody found a solution? Already set the @node-rs/argon2 package into the experimental object in next.config.mjs.

[Module32]

I get this issue with Next.js 14.2.3 without Turbopack and with the middleware.ts file. Has somebody found a solution? Already set the @node-rs/argon2 package into the experimental object in next.config.mjs.

Same here, anyone found a solution yet?

[timootten]

When I try to import the following using bun:

import { Argon2id } from "oslo/password";

I encounter this error:

error: Cannot find module "oslo/password" from "/usr/src/app/server/entries/pages/auth/login/_page.server.ts.js"

[timootten]

Solved by changing vite.config.ts:

import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vite';
import Inspect from 'vite-plugin-inspect';

export default defineConfig({
plugins: [Inspect(), sveltekit()],
ssr: {
noExternal: ['oslo']
}
});

[srkuleo]

I get this issue with Next.js 14.2.3 without Turbopack and with the middleware.ts file. Has somebody found a solution? Already set the @node-rs/argon2 package into the experimental object in next.config.mjs.

Same here, getting error when trying to Sign Up in development, even though I am not using trubo and switched to lucia v3 way of doing hashing/verifying, using Argon2id from "oslo/password" instead of legacy version with "node-rs/argon2".

Hope this gets fixed soon, really annyoing...

[prescarlton]

I get this issue with Next.js 14.2.3 without Turbopack and with the middleware.ts file. Has somebody found a solution? Already set the @node-rs/argon2 package into the experimental object in next.config.mjs.

I had the same issue. I found out it was because middleware.ts only runs in the Edge runtime, not the Node.js runtime. Almost all hashing libraries only work in the Node.js runtime. I ended up just not using middleware.

[kyrregjerstad]

Did anyone find a solution for this in NextJS with --turbo enabled?

[benhonda]

I'm using Astro 5.0.1. I had a bit of a brain fart. My issue was that, from the client, I was importing from a file that was importing from @node-rs/argon2, which is obviously server-only (would be the same issue if it was oslo/password, presumably).

For example:

// MyReactComponent.tsx 
// ...
import { something } from "../utils.ts";
// ...

// utils.ts
// ...
import { hash } from "@node-rs/argon2";
// ...
export const something = ...

This was causing Vite to bundle it, as expected, and that's when I got

✘ [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.

05:56:15 [ERROR] [UnhandledRejection] Astro detected an unhandled rejection. Here's the stack trace:

On a related note, I haven't seen anything about being able to mark a file/export as server-only in Astro - but please lmk if such a thing exists

[estani]

I get this issue with Next.js 14.2.3 without Turbopack and with the middleware.ts file. Has somebody found a solution? Already set the @node-rs/argon2 package into the experimental object in next.config.mjs.

I'm not using oslo but @node-rs/argon2 directly, but it might help pin pointing the problem, as I think is the same.

I have two files, the auth.config.ts that is used in the middleware, and the auth.ts one, which exports { auth, signIn, signOut, handlers } and uses auth.config.ts as well.

I moved the jwt callback (which requires a function from a file that imports @node-rs/argon2) from auth.config.ts to auth.ts and it worked.

So basically, make sure you don't import anything that imports @node-rs/argon2 in the middleware.js. As long as you only require the hash to be used in signIn or the handlers, you should be fine with splitting the config in two.