pilcrowonpaper / oslo

A collection of auth-related utilities
https://oslo.js.org
MIT License
1.12k stars 35 forks source link

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

Closed danestves closed 9 months ago

danestves commented 9 months ago

Getting the following error when using oslo with vite

pilcrowonpaper commented 9 months ago

What package manager are you using?

pilcrowonpaper commented 9 months ago

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

danestves commented 9 months ago

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 commented 9 months ago

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

pilcrowonpaper commented 9 months ago

Does npm run build also cause an error?

pilcrowonpaper commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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

pilcrowonpaper commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago
Framework Works out of the box
Astro
Nuxt
Remix
SolidStart
SvelteKit
Vite raw SSR
pilcrowonpaper commented 9 months ago

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: https://github.com/withastro/astro/issues/9859

pilcrowonpaper commented 9 months ago

The same issue is likely present in Remix

pilcrowonpaper commented 9 months ago

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

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

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 commented 9 months ago

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 commented 8 months ago

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 commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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.

image

Module32 commented 4 months ago

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.

image

Same here, anyone found a solution yet?

timootten commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.

image

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 commented 3 months ago

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.

image

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 commented 4 weeks ago

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