This ensures we use the `defaultLocale` for a locale domain when rendering non-static pages. Static pages will initially contain the global `defaultLocale` and then be updated on the client since we don't currently prerender a version of the pages for each locale domain.
Closes: https://github.com/vercel/next.js/issues/18970
This makes sure custom-routes function properly with i18n support. Since the `locale` is stripped from the `pathname` this re-adds when checking custom-routes to allow the locale to be matched against
Closes: https://github.com/vercel/next.js/issues/18349
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
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 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
Replace `url.parse` and `url.resolve` logic with whatwg `URL`, Bring in a customized `format` function to handle the node url objects that can be passed to router methods. This eliminates the need for `url` (and thus `native-url`) in core. Looks like it shaves off about 2.5Kb, according to the `size-limits` integration tests.
This adds additional checks against the routeKeys used to build the named regexes for dynamic routes to ensure they follow PCRE rules for named capture groups
x-ref: https://github.com/vercel/vercel/pull/4813
Noticed this while reviewing https://github.com/vercel/next.js/pull/14376. After having done https://github.com/vercel/next.js/pull/13699, this code didn't feel right to me:
```js
function prepareRoute(path: string) {
path = delBasePath(path || '')
// this /index rewrite is problematic, it makes pages/index.js
// and pages/index/index.js point to the same thing:
return toRoute(!path || path === '/' ? '/index' : path)
}
```
Added a nested index page to the prerender tests and found it was rendering the `/` route on navigation. This uncovered 2 more places around the dataroute where the index path was not translated correctly.
**edit:**
Just to note that there was nothing wrong with https://github.com/vercel/next.js/pull/14376, the issue was already there, I just noticed it while reading that PR
Noticed while working on https://github.com/vercel/next.js/pull/14400 that the optional catch-all handling was missing in `namedRegex`.
This whole file also seemed quite regex heavy so I took a look at the overall logic and changed a few things. It worked by regex escaping the whole route then unescape the dynamic parts. I changed it to only regex escape the static parts, this eliminates unnecessary back and forth escaping. It also makes the dynamic parts handling more readable. The whole logic is less reliant on regexes and just uses simple string manipulation to translate the route into a regex, I didn't measure anything but as an effect this should make it more performant.
This updates the named regexes output in the `routes-manifest` and the associated `routeKeys` to not use any non-word characters as this breaks the named regexes e.g. `"Invalid regular expression: "^/(?<data\-provider\-id>[^/]+?)(?:/)?$"`
x-ref: https://github.com/zeit/now/pull/4355
Fixes https://github.com/vercel/next.js/issues/13524
To do:
- [x] fix dev mode
- [x] there's a ~route ordering or~ trailing slash issue with top level catch-all (current tests reflect that)
- [x] in this test `/get-static-paths/whatever` should fall back to `/[[...optionalName]].js` since `fallback` is `false` in its `getStaticPaths` method. ~Currently seems to 500~ must have been a glitch
- [x] add tests for `null`, `undefined` ~and `false`~ behavior as well (if decided these are valid)
- [x] ~add tests for string params as well~ this is not allowed for catch-all routes
- [x] test behavior when fallback is enabled and a top level catch-all exists
* Generate sourcemaps for core files that pass through Babel
* Run files through Babel instead of tsc
* Get rid of wildcard helper
* Get rid of wildcard helper
* Remove unused file
* Update wildcard imports
* Add exclude
* Get rid of object-assign helper
* Use Object.assign as it gives better output
Co-authored-by: Joe Haddad <joe.haddad@zeit.co>
* Catch-all Route Support
* Add SSR tests
* Add additional test
* Add unit tests
* Put the feature behind a flag
* Apply suggestions from code review
Co-Authored-By: JJ Kasper <jj@jjsweb.site>
* Fix test
This refactors the `handleSlug` method in preparation for catch-all routing.
This PR is opened separately so the catch-all diff can be reviewed easier.
