[Feature Request] Dynamic asset prefixes in next start

[blairmcalpine]

At the moment, custom Next.js servers (ie those not started with next start) support the concept of dynamic asset prefixes. That is, the asset prefix for the served HTML can be changed dynamically at request time using app.setAssetPrefix.

When using next start, this behaviour isn't replicated. The only choice that is given is a static asset prefix in the config, which of course cannot be changed per-request.

At Faire, we localize our client bundles at build time, so we need to have different assets depending on the locale of the request. Right now, we have to use a custom server that wraps the Next.js request handler in order to "hack" this dynamic asset approach into existence. Admittedly we could update our approach to use app.setAssetPrefix, but what we'd really like is just to have no custom server at all and be able to use next start.

I would propose two possible solutions to this:

1. API to set the asset prefix in middleware

the NextResponse functions could be updated to include another option to their ResponseInit and MiddlewareResponseInit parameter, called assetPrefix. This allows middleware to reason about what asset prefix should be used, before passing it off to be handled.

Example:

middleware.ts:

export async function middleware(request: NextRequest) {
    const assetPrefix: string = getAssetPrefixBasedOnRequest(request)
    return NextResponse.next({
       assetPrefix
    })
}

2. Updated assetPrefix option in next.config

The assetPrefix option could be updated in the next.config to also support a function (alongside the existing static string), which can be called at request time:

next.config.ts:

const config = {
    // Can now be a function OR a string
    assetPrefix: (request: NextRequest) => {
        const assetPrefix: string = getAssetPrefixBasedOnRequest(request)
        return assetPrefix
    }
}

export default config;

I have no preference between the two approaches and I'm sure one is much more feasible than the other in terms of implementation, but just wanted to include both.