Advanced assetPrefix

[Netail]

Goals

1. More control over the assetPrefix
2. AssetPrefix per client / server

Background

Currently NextJS supports 2 kind of assetPrefixes; relative & absolute (but only the host).

If you use a relative url (e.g. /custom-prefix), the client uses the current host + the relative path to fetch the bundles & the server hosts the bundles on the relative path.

If you use an absolute url, but only the host, (e.g. https://cdn.website.com) it fetches the bundles from the new host from the root & the server hosts the bundles on the root path

Issue

However, if you use an absolute url WITH a path. (e.g. https://cdn.website.com/custom-prefix) The client fetches the bundles from the new host + path, while the server serves the bundles from the root (in stead of the path of the absolute url). Resulting in a 404 for fetching the bundles. (could even be considered a bug?)
-> Client call FETCH https://cdn.website.com/custom-prefix/_next/static/<bundles>
-> Server serves bundles on <internal_url>/_next/static/<bundles> (missing path prefix from absolute url)

Proposal

Method 1

assetPrefix: string;

For backwards compatibility assetPrefix can stay a string.
-> If the assetPrefix is a relative url, it can be used by the client & server.
-> If the assetPrefix is a absolute url, the client uses the full absolute url, while the server only uses the path.

Method 2

assetPrefix: {
	host: string;
	path: string;
}

Client uses host + path, while the server uses only the path. Easier than having NextJS to parse. Maybe only use the host in production builds as it makes no sense to point to a deployed build when running locally.

Note

The above 2 methods keep the path in sync between the client & server, but we could let the consumer customize even more.
This however, does give NextJS' assetPrefix functionality more complexity as a consumer could mismatch paths easily, but does give you more customisation if you have some routing in front of your NextJS app.

Method 3

assetPrefix: {
	client: string; // (absolute or relative url)
	server: string; // (only relative url)
}

Method 4

assetPrefix: {
	client: {
		host: string;
		path: string;
	}
	server: {
		path: string;
	}
}

Method 5

assetPrefix: string; // (absolute or relative url)
serverAssetPrefix: string; // (only relative url)

[Netail]

Part of this could also include a dynamic assetPrefix, which you can set on runtime, so you can set a CDN host for e.g. the production deployment, but not for the test/acceptance/development deployment, while using the same docker build.

Instead of having to create a custom pre-run script to replace this assetPrefix, like: #18301 (comment)

[Netail]

Maybe something similar to nuxt, where you can set a CDN_URL through a process variable; https://nuxt.com/docs/api/nuxt-config#cdnurl

[Netail]

Part of this could also include the customisation of /_next/, maybe that being the default assetPrefix path? (I've seen a few requests for this already)