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
### Description
Adds config for experimental PPR support
### Related Issue(s)/Incident
Prior art: #57444
### Best Way to Test
Visit → docs/app/api-reference/next-config-js/partial-prerendering
Co-authored-by: Amy Burns <5012825+timeyoutakeit@users.noreply.github.com>
Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
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
This PR is a combination of many months of feedback from the community
on how to self-host with Next.js. It's became clear talking to many of
y'all that there is confusion about if all features are supported when
self-hosting, and what implications this has when using third-party
providers.
The deployment docs now clarify that all features are supported when
self-hosting. However, this comes with important notes. First, we're
building a standard deployment output, not adapters. We want these docs
to ensure that if you follow what's described on this page, you're going
to have a good experience with Next.js and will be able to take
advantage of all features. Previously, we had to add caveats in here
about different providers and their level of support. We are not doing
that anymore.
Instead, we're providing further details on different features and how
they can be configured when self-hosting. These docs have existed in
other locations (e.g. the specific API pages in our docs), but I've
combined and simplified them here so there's one page you need to read
to learn about all of the options. If you self-host Next.js anywhere
with a Node.js server, Docker container, or static HTML export, all of
the following features will work as expected. Further, we've added other
specifics around self-hosting ISR / Data Cache and configuring your
caching location, which is important when self-hosting with Kubernetes.
Finally, there has been a common feature request to allow runtime
environment variables, rather than statically inlining the values during
the build. While this was possible with `getServerSideProps` in the
Pages Router, if the value needed to be used on the component body, this
option didn't work, as it needed to be serialized and forwarded to the
component. With the App Router, this problem is solved, since Server
Components can render entirely on the server. Thus, when dynamically
rendering, you can just use `process.env.MY_VALUE` and it works.
I also toned down the Vercel section, because, it was a bit much TBH.
Related: https://github.com/vercel/next.js/pull/57953
---------
Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
### What
Corrects how urlassetreference reads its assets path to allow to resolve image assets correctly.
There is a test failure in the integration/url still, that involves probably larger refactoring so making this PR first to enable baseline, ensure further refactoring does not breaks anything.
This auto-generated PR updates the integration test manifest used when testing Turbopack.
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
Doesn't make any functional changes. Going through the current setup for isolated tests to figure out a better way to cache the repository setup, so that we don't have to wait ~30s+ when running tests locally.
Reverts vercel/next.js#57154
Brings back the changes but uses the compiled version of async-retry instead. Previously these changes causes an error as async-retry wasn't installed.
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.