This PR fixes a bug where parallel routes would not apply appropriately on navigation when used within slots.
The following scenarios:
```
/foo
/bar
/@slot
/[...catchAll]
```
or
```
/foo
/[...catchAll]
/@slot
/bar
```
will now function correctly when accessing /foo/bar, and Next.js will render both /bar and the catchall slots.
The issue was that the tree constructed by `next-app-loader` for a given path, /foo/bar in the example, would not include the paths for the catch-all files at build time. The routing was done 1-1 when compiling files, where a path would only match one file, with parallel routes, a path could hit a defined path but also a catch all route at the same time in a different slot.
The fix consists of adding another normalisation layer that will look for all catch-all in `appPaths` and iterate over the other paths and add the relevant information when needed.
The tricky part was making sure that we only included the relevant paths to the loader: we don't want to overwrite a slot with a catch all if there's already a more specific subpath in that slot, i.e. if there's /foo/@slot/bar/page.js, no need to inject /foo/@slot/bar/[...catchAll].
One thing that is not supported right now is optional catch all routes, will add later.
fixes#48719fixes#49662
Instead of requiring React in `maybePostpone` (which is susceptible to referencing the wrong version of React during build time, such as in the case where the static worker patches fetch within an app-route, which doesn't have an experimental runtime), this provides the postpone API to the `staticGenerationStore`. That way we know the API is available in render which is when we'd expect to postpone.
The "postpone" terminology is internal to React and can be used for more
things than just this. It's also a mechanism we may or may not rely on.
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
Fixes a broken link, shortens the title, and adds another possible way
to resolve the error.
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This PR fixes the bug in which interception routes of the form `(.)[param]` would not intercept navigations.
The bug happened because we would not create a dynamic route matcher for the intercepted route, so we would never match the correct dynamic route when hitting the server, falling back to the base one.
The fix consists of fixing the logic that checks for a dynamic route so that it checks the correct path when handling an interception route.
There's probably a better fix here, advice welcome
fixes#52533
React can emit a `Link:` header for preloads instead of `<link
rel="preload">` in certain scenarios when that can be useful. This works
by listening to the `onHeaders` event.
In particular it's interesting for PPR because if you have something
dynamic outside a Suspense boundary it generates an empty payload
without any preloads in it. That's because when we do render the real
shell we don't know what the document will look like. However, we can
emit the `Link` header for CSS, images and font preloads that we've
already discovered. In effect, even a dynamic page gets PPR benefits by
early fetching resources.
Custom headers is supported for static a ROUTE but not a PAGE. So I had
to add similar wiring to forward headers when it's a page being
rendered.
It's important that this works every where, including dynamic routes,
because otherwise we might miss out on preloads that we previously
would've had.
Fixes two build output logs:
- A page that uses `generateStaticParams` & postpones should be marked as partially prerendered
- Assume pages that contain dynamic segments will postpone when PPR is enabled even though it won't be determined until request time
When `patchFetch` is applied at during `buildAppStaticPaths` ([ref](030021234b/packages/next/src/build/utils.ts (L1253-L1256))), it's done so without any context of the bundled React runtime.
Since `patchFetch` will potentially postpone during static generation with PPR, it needs to be using the correct React version, otherwise `unstable_postpone` won't be available e.g. in the case of a page utilizing `generateStaticParams`.
This moves `patchFetch` into the bundled runtime so that it has the correct version of React when invoked.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What?
Since the Wasm fallback was re-introduced in
https://github.com/vercel/next.js/pull/57906 I am now also adding a
check for detecting WebContainers so that it would always use the SWC
Wasm fallback. That's because WebContainers can't execute native
binaries.
I decided to not account for `NEXT_DISABLE_SWC_WASM` because it doesn't
make much sense and if someone had this enabled, it would always fail.
But if ya all think it's better to take this flag into account then I am
happy to change it.
### What?
fixes a problem with cache invalidation when the next.js folder moves in node_modules, but the version stays equal
### Why?
This can happen when pnpm creates a new next.js copy with different peerDependencies.
