feat: add option to define NEXTAUTH_URL via next runtime config

[grikomsn]

What:

Resolves #1156, this PR adds an option to define NEXTAUTH_URL via Next.js runtime configuration.

Why:

By design, NextAuth.js retrieves NEXTAUTH_URL value via environment variables. Some cases requires dynamically generated canonical URL (e.g. multi-stage environments and multi-tenancy websites) and cannot set environment variables dynamically (e.g. Vercel for prod/prev/dev environments).

With this proposed PR, NextAuth.js can read NEXTAUTH_URL value from Next.js runtime configurations via publicRuntimeConfig.NEXTAUTH_URL property on the project's next.config.js file.

How:

This is approached by creating a function which returns either from NEXTAUTH_URL environment variable or from the runtime configuration. If via env, the runtime config will be ignored.

Checklist:

• Documentation
• Tests (see note below)
• Ready to be merged

Additional notes:

• Building locally works and already being used in production deployment
• If needed, add another approach to compose NEXTAUTH_URL via Vercel's system environment variables
• next is a dev dependency but is being used in server/client code, probably change as peer dependency?

Note to maintainers:

This PR is heavily opinionated and only serves as a temporary solution for those who really need a way to dynamically set NEXTAUTH_URL. If there is a better way to implement, or this approach is not aligned with NextAuth.js architecture, or anything, merge is optional. ✌🏻

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/nextauthjs/next-auth/pjd7ivkmd
✅ Preview: https://next-auth-git-fork-grikomsn-feature-next-runtime-config.nextauthjs.vercel.app

[iaincollins]

I've left a comment on this in #1156.

I think I get where you are going with this but don't think this a direction we want to go in as I don't think it does what people would hope it does (in the case of most OAuth providers) and I think it would probably cause confusion.

I did considering building it this way originally, and explored this with v2.x (originally v2 used an option) but it turns out it creates some interesting problems; especially for API route handling on some hosting platforms; and a race condition that was hard to spot. I lamentably chose a single env var as the least worst option.

If you could frame the conceptional challenge - e.g. "signing in with Google on Pull Request instances" and include any constraints (e.g. must support JWT sessions / must support a database, etc. - perhaps we can come up with some approaches?