Referencing NEXTAUTH_URL in app router causes build error for runtime environment variables

[c-kirkeby]

Environment

(From CodeSandbox)
System:
OS: Linux 6.1 Debian GNU/Linux 11 (bullseye) 11 (bullseye)
CPU: (2) x64 AMD EPYC
Memory: 400.73 MB / 2.01 GB
Container: Yes
Shell: 5.8 - /bin/zsh
Binaries:
Node: 20.9.0 - /usr/local/bin/node
Yarn: 1.22.19 - /usr/local/bin/yarn
npm: 9.8.1 - /usr/local/bin/npm
pnpm: 8.10.2 - /usr/local/share/npm-global/bin/pnpm
npmPackages:
next: latest => 14.0.3
next-auth: beta => 5.0.0-beta.3
react: ^18.2.0 => 18.2.0

Reproduction URL

https://github.com/c-kirkeby/next-auth-example

Describe the issue

Referencing NEXTAUTH_URL in the app directory causes builds to fail if NEXTAUTH_URL is not available at compile time. This is causing issues in CI when we build a docker image that uses environment variables at runtime. I've modified the next-auth-example to use the cookies option in the auth config. In attempting to figure out how to make this work I've put unsable_noStore() and export dynamic = 'force-dynamic' in just about every page and it still doesn't work.

The GitHub bot was unhappy when I linked to Codesandbox last time so I've added the attached repo instead but the link to Codesandbox is here.

How to reproduce

Open the CodeSandbox and npm run build. Do not set any environment variables for the build as they should be defined at runtime.

Expected behavior

As far as I understand, next-auth shouldn't be trying to access the environment variables at build time if we opt into dynamic rendering.

[balazsorban44]

This makes sense and is expected. Some routes might be rendered at build time, so this variable needs to be present then as well. FWIW, this variable is rarely needed anymore, what's the use case?

[c-kirkeby]

For our particular use case we're sharing a secure cookie to have a persisted session token across our subdomains such as this approach here. This works so long as we use the page router, but if we try to migrate to the app router we get an error at build time.

[balazsorban44]

This can be addressed, as lazy initialization (prev. advanced initialization) is now supported in v5 too. see #9638