Custom login page is not working when using turbopack (nextjs v15)

[pacoorozco]

Environment

  System:
    OS: Linux 6.8 Ubuntu 24.04.3 LTS 24.04.3 LTS (Noble Numbat)
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
    Memory: 21.08 GB / 31.06 GB
    Container: Yes
    Shell: 5.2.21 - /bin/bash
  Binaries:
    Node: 22.17.0 - /run/user/1000/fnm_multishells/117412_1767514956193/bin/node
    npm: 10.9.2 - /run/user/1000/fnm_multishells/117412_1767514956193/bin/npm
  Browsers:
    Chrome: 143.0.7499.169
    Firefox: 146.0.1
    Firefox Developer Edition: 146.0.1
  npmPackages:
    next: 15.5.9 => 15.5.9 
    next-auth: ^5.0.0-beta.30 => 5.0.0-beta.30 
    react: 19.2.3 => 19.2.3 

Reproduction URL

https://test-next-auth-theta.vercel.app/

Describe the issue

After building an app using next-auth@beta + NextJS v15 + Turbopack, the console shows an error when the custom login page is shown. It uses a custom login page

If you use it using npm run dev everything works very well. But if you run npm run build and npm run start the browser console shows an error like the attached image

I believe it's a problem when building with turbopack because it's working when you're not using it.

Repository is available here

How to reproduce

1. Build the app: npm run build
2. Serve it npm run start
3. Go to: localhost:3000, the app will redirect you to /signin
4. The page is not rendered properly and it shows errors on the browser console

Expected behavior

The login page should be shown properly and we should be able to log in

[pacoorozco]

I've modified the code to just use plain Credentials... the error is still reproducible.

[pacoorozco]

I've updated NextJs to v16 and it's fixed there, so I guess it's a turbopack issue rather than next-auth.

[jonas-is-coding]

This looks like a type boundary problem rather than a runtime logic issue. The most reliable fix is to make the input/output contract explicit at the entry point, validate unknown data before it reaches typed code, and avoid widening to any in shared paths. If the failure appeared after an upgrade, pinning to the previous known-good version while narrowing the contract usually removes the regression without introducing hidden behavior changes.