Follow-up to https://github.com/vercel/next.js/pull/17370 this adds mapping of locales to domains and handles default locales for specific domains also allowing specifying which locales can be visited for each domain.
This PR also updates to output all statically generated pages under the locale prefix to make it easier to locate/lookup and to not redirect to the default locale prefixed path when no `accept-language` header is provided.
Follow-up PR to https://github.com/vercel/next.js/pull/17370 when the path is not prefixed with a locale and the default locale is the detected locale it doesn't redirect to locale prefixed variant. If the default locale path is visited and the default locale is visited this also redirects to the root removing the un-necessary locale in the URL.
This also exposes the `defaultLocale` on the router since the RFC mentions `Setting a defaultLocale is required in every i18n library so it'd be useful for Next.js to provide it to the application.` although doesn't explicitly spec where we want to expose it. If we want to expose it differently this can be updated.
This adds the initial changes outlined in the [i18n routing RFC](https://github.com/vercel/next.js/discussions/17078). This currently treats the locale prefix on routes similar to how the basePath is treated in that the config doesn't require any changes to your pages directory and is automatically stripped/added based on the detected locale that should be used.
Currently redirecting occurs on the `/` route if a locale is detected regardless of if an optional catch-all route would match the `/` route or not we may want to investigate whether we want to disable this redirection automatically if an `/index.js` file isn't present at root of the pages directory.
TODO:
- [x] ensure locale detection/populating works in serverless mode correctly
- [x] add tests for locale handling in different modes, fallback/getStaticProps/getServerSideProps
To be continued in fall-up PRs
- [ ] add tests for revalidate, auto-export, basePath + i18n
- [ ] add mapping of domains with locales
- [ ] investigate detecting locale against non-index routes and populating the locale in a cookie
x-ref: https://github.com/vercel/next.js/issues/17110
Prior to this pull request, Next.js would immediately decode all URLs sent to its server (via `path-match`).
This was rarely needed, and Next.js would typically re-encode the incoming request right away (see all the `encodeURIComponent`s removed in PR diff). This adds unnecessary performance overhead.
Long term, this will also help prevent weird encoding edge-cases like #10004, #10022, #11371, et al.
---
No new tests are necessary for this change because we've extensively tested these edge cases with existing tests.
One test was updated to reflect that we skip decoding in a 404 scenario.
Let's see if all the existing tests pass!
This makes sure we properly resolve a rewrite when only the `href` value is used. This was causing a full-reload and was missed in the existing test since we weren't making sure a full navigation didn't occur which has been added in this PR.
Fixes: https://github.com/vercel/next.js/issues/16974
Removes `next-head-count`, improving support for 3rd party libraries that insert or append new elements to `<head>`.
---
This is more or less what a solution with a `data-` attribute would look like, except that instead of directly searching for elements with that attribute, we serialize the elements expected in `<head>` and then find them/assume ownership of them during initialization (in a manner similar to React's reconciliation) based on their properties.
There are two main assumptions here:
1. Content is served with compression, so duplicate serialization of e.g. inline script or style tags doesn't have a meaningful impact. Storing a hash would be a potential optimization.
2. 3rd party libraries primarily only insert new, unique elements to head. Libraries trying to actively manage elements that overlap with those that Next.js claims ownership of will still be unsupported.
The reason for this roundabout approach is that I'd really like to avoid `data-` if possible, for maximum compatibility. Implicitly adding an attribute could be a breaking change for some class of tools or crawlers and makes it otherwise impossible to insert raw HTML into `<head>`. Adding an unexpected attribute is why the original `class="next-head"` approach was problematic in the first place!
That said, while I don't expect this to be more problematic than `next-head-count` (anything that would break in this new model also should have broken in the old model), if that does end up being the case, it might make sense to just bite the bullet.
Fixes#11012Closes#16707
---
cc @Timer @timneutkens
This makes sure to strip the trailing slash before attempting to resolve the `href` against pages/dynamic routes and adds tests ensuring the correct pages are resolved with `trailingSlash: true` enabled.
Fixes: https://github.com/vercel/next.js/issues/16872
This makes sure we only pass the as value's `pathname` instead of the full value so that we don't accidentally include `query` values while resolving the rewrites. This also adds tests to ensure the rewrites are resolved with the correct query values when only providing `href` and when manually mapping them with `href` and `as`
Fixes: https://github.com/vercel/next.js/issues/16825
This is a small change to the image post-processor logic. When it's looking for images to preload, it will now ignore SVGs, as these are rarely the relevant images for LCP.
This pull request replaces our client-side style transitions with `<style>` tags over async `<link rel=stylesheet>` tags. This should fix some edge cases users see with Chrome accidentally causing a FOUC.
This also removes the need to perform an async operation before starting the render, which should remove any perceivable navigation delay.
---
Fixes#16289
When navigating from a non-shallow page to a page that was navigated to shallowly in history it causes incorrect page data to be shown since an incorrect shallow navigation is done. We can only maintain shallow routing when the current page was navigated to shallowly and the page being navigated to in history was also navigated to shallowly. Additional tests to ensure this behavior is working has also been added.
Closes: https://github.com/vercel/next.js/issues/7395
Closes: https://github.com/vercel/next.js/issues/14928
Fixes: https://github.com/vercel/next.js/issues/16028
This pull request correctly tracks render cancelation behavior. Prior to this PR, we'd have an unhandled rejection that left the app in a bad state and no routeChangeError event was fired.
---
Closes#16424Fixes#16445
This makes sure to also check if a dynamic route matched after resolving a rewrite on the client to match behavior on the server. It also adds tests for this behavior to ensure it is working properly.
Fixes: https://github.com/vercel/next.js/issues/16454
This fixes a client-side file not being transpiled correctly when rewrites are used. The cross browser tests have been updated to make sure there are rewrites so the related code is included and not dead-code eliminated'
Closes: https://github.com/vercel/next.js/issues/16440
This pull request adds a test case for the reproduction provided in #12445. This bug is specifically caused when loading the next page before navigation has actually occurred.
---
Fixes#12445
This fixes the incorrect `/_next/data` URL being generated on client transition due to the `as` value passed to `getRouteInfo` having the `basePath` which is used while interpolating the values for dynamic routes, specifically root catch-all routes. A regression test has also been added to ensure this is working
Closes: https://github.com/vercel/next.js/issues/15747
This updates to not automatically append params to the query for rewrites if one or more of the params are already used in the destination's path. No other behavior is being changed and if the user still wants the params in the query after using them in the destination's path they can manually add them like with redirects.
Closes: https://github.com/vercel/next.js/issues/15626
This PR removes a legacy router method that was used for old-style HMR, now replaced by Fast Refresh.
This method was not public:
```tsx
export type NextRouter = BaseRouter &
Pick<
Router,
| 'push'
| 'replace'
| 'reload'
| 'back'
| 'prefetch'
| 'beforePopState'
| 'events'
| 'isFallback'
>
```
Even if someone found this method, it's highly unlikely they could use it successfully—it required the full module object.
This PR adds a second experimental post-processing step for the framework introduced by @prateekbh in #14746. The image post-processing step scans the rendered document for the first few images and uses a simple heuristic to determine if the images should be automatically preloaded.
Analysis of quite a few production Next apps has shown that a lot of sites are taking a substantial hit to their [LCP](https://web.dev/lcp/) score because an image that's part of the "hero" element on the page is not preloaded and is getting downloaded with lower priority than the JavaScript bundles. This post-processor should automatically fix that for a lot of sites, without causing any real performance effects in cases where it fails to identify the hero image.
This feature is behind an experimental flag, and will be subject to quite a bit of experimentation and tweaking before it's ready to be made a default setting.
In terms of url rewriting, `trailingSlash` supports everything `exportTrailingSlash` does. We can just share all other code paths and deprecate `exportTrailingSlash`.
This PR shows a deprecation warning when `exportTrailingSlash` is used.
Also fixes https://github.com/vercel/next.js/issues/15774
We can update the tests now or later. (I kept them the same to prove it's non-breaking)
To do:
- [x] Do we want to keep this? => nope 841d4efc51/packages/next/next-server/lib/router/router.ts (L329)
- [x] I kept `exportTrailingSlash` here. Do we want to rename that as well? => nope 2d9d649d49/packages/next/build/index.ts (L959)