In development when handling the page request, we are sending the
parsedUrl with the basePath stripped but not assetPrefix. As a result,
when setting an assetPrefix, the chunk would 404 which causes a hard
nav. It'd then recover and work correctly on subsequent navs.
This applies the exact same handling we had for basePath, but for
assetPrefix.
Fixes#77241
This PR fixes two issues with the use of `assetPrefix`:
#1: https://github.com/vercel/next.js/issues/64710
`assetPrefix` needs to be handled in `dev`, `deploy`, and `start`. In
the current approach, only `dev` and `start` were handled, but a quirk
of the implementation caused rewrites for non-asset paths to not be able
to be used in `afterFiles` rewrites.
#2: When deploying Next.js (such as on Vercel), you need to add your own
`beforeFiles` rewrite for `/${assetPrefix}/_next/...` requests or
otherwise they would 404.
This PR creates an automatically added `rewrite` to `beforeFiles` that
handles the case for `dev`, `start`, and `deploy`, removes the existing
logic in `filesystem.ts`, and adds more tests to check the behavior.
Closes: https://github.com/vercel/next.js/issues/63623
When a relative assetPrefix was set (e.g. `/custom-asset-prefix`),
bundle fetching would always return a 404 as the assetPrefix was not
removed from filesystem path
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
`_devPagesManifest.json` and `_devMiddlewareManifest.json` will fail to load when using an asset prefix. In conjunction with i18n, this causes the app to get caught in an infinite load loop.
### Why?
We're expecting these paths to be exact matches but when there's an assetPrefix specified, they won't be matched.
### How?
This copies similar behavior to how we handle [`webpack-hmr`](https://github.com/vercel/next.js/blob/2e2211d27b3f0ff1cff5553453df4cf391996163/packages/next/src/server/lib/router-server.ts#L681) by doing a partial match on the URL when serving it
Closes NEXT-1618
Fixes#55389
Zack Tanner