Node.js ships with a built-in `fetch` now so `node-fetch` is no longer
necessary. Mostly motivated by tracing Node.js deprecation warnings
which originated from `node-fetch` by calling the deprecated
`url.parse`.
Call sites keep working through a compatibility type on `fetchViaHTTP`
that translates node-fetch-only options: Instead of `agent` we pass to
`http(s)` directly, `timeout` becomes `AbortSignal.timeout`, and Node.js
readable streams are accepted as bodies with `duplex: 'half'` set
automatically.
The `abort-controller` polyfill is dropped since its signal type
predates the current AbortSignal and undici would not honor it.
`node-fetch` stays installed because `scripts/generate-release-log.mjs`,
`scripts/reset-project.mjs`, and `scripts/update-google-fonts.js` still
import it (follow-up material). Fixture apps will be migrated
separately.
*This doesn't enable skew protection for any new tests, only preparation*
Prepare a lot of test assertions so that they work correctly when a `?dpl=123` query param is present:
- some regexes should accept the query
- some places assumed that the `<script>`'s `src` is a valid pathname, whereas it might have a query param that has to be stripped before removing the path
- some hardcoded build ids instead of `next.buildId`
Closes PACK-6539
When `experimental.runtimeServerDeploymentId` is enabled, read the `process.env.NEXT_DEPLOYMENT_ID` and append to the chunks when evaluating the `client-reference-manifest.js`
Originally, I tried to do it after the manifest is loaded (in `loadComponents` or in the `RouteModule.prepare`) to "hydrate" the manifest, but that is too late because the manifest needs to be initialized immediately to make module-evaluation-time server actions work (which need the manifest immediately)
This moves `experimental.cacheComponents` to a top level config. As part
of this, I disabled some tests in `build-output-prerender` that assert
on `cacheComponents` appearing in the experimental list. In a separate
PR, I'm going to show that Cache Components is enabled next to the
bundler info.
This also updates some docs pages to remove "experimental" language.
This hard deprecates the `experimental.ppr` configuration, requiring
users to opt-in instead via `experimental.cacheComponents`. This does
mean that the previous `experimental.ppr = "incremental"` will no longer
be supported.
NAR-433
Enabling `experimental.isolatedDevBuild` required many changes to the
current workflow, so we will incrementally roll out to the tests.
Enabling on test-dev instead of test-experimental-dev because
`-experimental` CIs are filtered via `experimental-tests-manifest.json`
and they don't cover all tests. We want to enable this feature by
default so we should ensure this incremental rollout is covered on all
test cases.
The flag was enabled for `test-experimental-dev` at
https://github.com/vercel/next.js/pull/84099, and this PR moves the flag
to the `test-dev` job.
1. ~~test-experimental-dev
([link](https://github.com/vercel/next.js/pull/84099))~~
2. test-dev (here)
3. test-prod
4. test-integration
5. test-unit
6. Enable by default, remove the flag, and update the rest
x-ref: https://github.com/vercel/next.js/pull/84043
Fixes edge runtime pages with dynamic routes returning 500 errors when
the URL segment literally contains bracket syntax that matches the
folder name (e.g., accessing `/[id]` for a route defined as
`/[id]/page.tsx`).
The removal of web-server.ts in #81389 modified how route params were
extracted for dynamic routes. The route matcher in prepare() was being
created with the full internal page path (e.g., /[id]/page) which
generated a regex expecting /page at the end. However, actual URL
pathnames don't include the /page suffix, causing the matcher to fail
when trying to extract params. This issue specifically manifested when
the URL contained literal brackets (like /[id]), as the fallback param
extraction would fail and leave params empty, leading to the error.
This PR normalizes the page path using before creating the route matcher
in prepare(). This ensures the regex pattern matches the actual URL
pathname format (without /page suffix).
Fixes NEXT-4698
we define most of the app router headers with capital letters, like
this:
```ts
export const NEXT_ROUTER_PREFETCH_HEADER = 'Next-Router-Prefetch' as const
```
which means we have to keep lowercasing the header everywhere when
checking for its presence, because node and other intermediate layers
normalize all headers to lowercase:
```ts
if (req.headers[NEXT_ROUTER_PREFETCH_HEADER.toLowerCase()]) { ... }
```
this seems pretty pointless -- we can just define the headers in
lowercase form, and skip all those `toLowerCase()` calls.
(all the above sentences have been normalized to lowercase to match the
spirit of this pr)
For all RSC requests, we require the `_rsc` search param to match the
hash of its corresponding RSC headers. In the case where the match
fails, we respond with a redirect to the correct search param. This hash
check only applies to `next start` mode for now.
Some tests in `rsc-basic` asserts that certain nodes should be empty,
but streaming metadata can get in there and break that expectation.
- i switched the test to use a full browser. this is better than
checking the raw html, because then react gets rid of any `<template>`
tags inside the div (which are used for streaming SSR things)
- we're also now only asserting that the inner text of the node should
be empty, which avoids failures because of a `<div hidden>` inserted by
streaming metadata. this is a slightly weaker assertion than "this node
has no children at all" but it should be enough for our purposes here.
also reverts #78449 and #78424, they were meant for debugging this issue
follow up to #78424. annoyingly, it appears that the console.log output
gets swallowed by jest somehow, so i'm using `require('console')`
instead which jest doesn't instrument.
rip. you served a purpose once, but now you're just getting in the way. this improves typesafety quite a bit, because `BrowserInterface` had a whole bunch of random `any`s everywhere
also
- removes `evalAsync`. no idea why that was needed, but we're happily using promises in normal eval, so it can be dropped
- adds more safety to `chain`
I've been seeing this test flake with some regularity:
---
● app dir - rsc basics › should be able to navigate between rsc routes
```
request.allHeaders: Target page, context or browser has been closed
168 | page.on('request', (request) => {
169 | requestsCount++
> 170 | return request.allHeaders().then((headers) => {
| ^
171 | if (
172 | headers['RSC'.toLowerCase()] === '1' &&
173 | // Prefetches also include `RSC`
at Page.allHeaders (e2e/app-dir/rsc-basic/rsc-basic.test.ts:170:26)
```
---
[Example test run
here](https://github.com/vercel/next.js/actions/runs/14313872710/job/40115445718?pr=77898#step:33:3431)
The error is actually unrelated to `should be able to navigate between
rsc routes`, and is coming from async operations (that haven't completed
in time) in another test in the same suite, `should reuse the inline
flight response without sending extra requests` .
I've de-asyncified the test's `page.on('request')` handler -- we don't
need the async `allHeaders()`, `headers()` is enough.
(I verified this by adding a client component that manually sends a
request with `RSC: 1`, and that does indeed trigger our request
listener).
I've also added a `waitForIdleNetwork` to hopefully make it complete all
requests before the test ends.
- `newDevOverlay: true` by default (enables experimental React builds on
canary until owner stacks progress further)
- `run-tests` now sets the env var for tests that were relying on it for
forking behavior
- PPR runners now run with the flag disabled to help catch regressions
in the old overlay until we remove it
- Fixed a number of tests that had outdated snapshots or missed forking
behavior because they weren't running in CI
- Disabled a test that was failing in Turbopack + Experimental React
that is unrelated to the overlay (see:
https://github.com/vercel/next.js/pull/75989)
---------
Co-authored-by: devjiwonchoi <devjiwonchoi@gmail.com>
Pages router (`/pages`) will continue to support React 18 not the React
19 RC. Current thinking is that we'll add support for React 19 in Pages
Router once 19 is stable.
This does not affect App Router (`/app`) which continues to use the
latest React Canary (i.e. React 19).
https://github.com/vercel/next.js/pull/65058 is required reading to
understand the changes in this PR
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
### What
When statically generating a page, Next.js will attempt to render the
application tree twice, resulting in unexpected calls to upstream APIs
and also slowing down the application during build as it needs to make 2
passes for the same data.
### Why
Next.js currently calls React's `renderToReadableStream` API in two
spots: once for the HTML render, and again for the Flight render. This
is because we want to generate a `.rsc` output for statically generated
pages, so that on navigation, we don't need to call the server to
retrieve the flight payload.
### How
Rather than calling `renderToReadableStream` twice, this refactors the
approach to instead only perform it once. This introduces a new type to
describe the response from calls to `createFromFetch`: `RSCPayload`,
including a set of utils to access the relevant payload data, as it can
change depending on calling context.
- During the initial SSR response & when statically generating the
flight payload, this will be an object containing the top-level props
that are used to render `<AppRouter />`
- For dynamic pages, this will only return the diffed component tree,
which is computed by `walkTreeWithFlightRouterState` traversing the
provided `next-router-state-tree` (from the client) to determine where
to start rendering (**this is unchanged from today**)
- For server actions, this will return the action result, in addition to
the same payload as above (**this is also unchanged**)
Fixes#58736Fixes#43254Fixes#60562
Closes NDX-17
### What
Add new test case where a named export from client component is being
exported as page
### Why
We found this case while investigating the errors triggered introduced
by #66286 , adding this test to avoid future regression
### What
Fix a bug introduced in #65694 , use app-page runtime for app router
layers
### Why
This is basically reverted the route context picking up logic we had
before.
During the test we found the error thrown
> Module not found: shared-runtime module router-context cannot be used
in rsc layer
Which is caused by a `next/router` imports in rsc page. Decided to
revert to what it was before as the most safe way to load share module
contexts.
It's caused by `next-contentlayer` usage that they're using
`next/router` in server component MDX, but we cannot lint error that
from node_modules. (We actually can, but disabled that due to various
mis-usage of server/client hooks we had before)
# Turbopack
* https://github.com/vercel/turbo/pull/7027 <!-- Donny/강동윤 - Update `swc_core` to `v0.87.28` -->
---
### What?
Update swc crates
### Why?
Required for #57718.
`styled-jsx` crate now has a hook to transform CSS code using a
Rust-side API
### How?
Fixes#57718
Closes PACK-2256
In #59725 I skipped this test in PPR prod mode, but not dev because CI
wasn't failing for dev. The idea was to investigate the failure
post-merge because it wasn't block-worthy.
But the test did fail in dev mode when CI ran on canary. So this updates
the guard to skip in dev, too.
Will follow up with a PR to fix the test itself.
Closes NEXT-1913
Exposes the new experimental Taint APIs using the `taint` flag which
enables experimental React.
As an example for how we can use it, I use it to taint `process.env`
with a better error message. I'm not sure where this should live since
it's a global init but it needs access to the global config. It's
unnecessary to retaint it for every render but not sure if there's a
better place for it.
---------
Co-authored-by: Jimmy Lai <laijimmy0@gmail.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This PR adds the optional `limit` parameter on String.prototype.split uses.
> If provided, splits the string at each occurrence of the specified separator, but stops when limit entries have been placed in the array. Any leftover text is not included in the array at all.
[MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/split#syntax)
While the performance gain may not be significant for small texts, it can be huge for large ones.
I made a benchmark on the following repository : https://github.com/Yovach/benchmark-nodejs
On my machine, I get the following results:
`node index.js`
> normal 1: 570.092ms
> normal 50: 2.284s
> normal 100: 3.543s
`node index-optimized.js`
> optmized 1: 644.301ms
> optmized 50: 929.39ms
> optmized 100: 1.020s
The "benchmarks" numbers are :
- "lorem-1" file contains 1 paragraph of "lorem ipsum"
- "lorem-50" file contains 50 paragraphes of "lorem ipsum"
- "lorem-100" file contains 100 paragraphes of "lorem ipsum"
This consolidates how we're evaluating when to opt into `react@experimental` since it's sprinkled in a lot of spots. Also adds a new flag to opt into the experimental channel
Closes NEXT-1632
While investigating the `next start` CPU profile noticed that this
function was called many times and that the JSON.parse happened for each
of them. This replaces that to no longer be needed and leverages the
require cache instead. The reason I didn't go for memoizing this
function is that it would add further complexity and potential for
leaking memory compared to the approach implemented in this PR.
<!-- 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
This PR changes Next.js to bundle its vendored React libraries so that the App Router pages can use those built-in versions.
## Why
Next.js supports both Pages and App Router and we've gone through a lot of iteration to make sure that Next.js stays flexible wrt to the version of React used: in Pages, we want to use the React provided by the user and in the App Router, to be able to use it, we need to use the canary version of React, which we've built into Next.js for convenience.
The problem stems from the fact that you can't run two different instances of React (by design).
Previously we have a dual worker setup, where we would separate completely each Next.js versions (App and Pages) so that they would not overlap with each other, however this approach was not great performance and memory wise.
We've recently tried using an ESM loader and a single process, but this change would still opt you into the React canary version if you had an app page, which breaks some assumptions.
## How
A list of the changes in this PR:
### New versions of the Next.js runtime
Since we now compile a runtime per type of page (app/route/api/pages), in order to bundle the two versions of React that we vendored, we introduced a new type of bundle suffixed by `-experimental`. This bundle will have the bleeding edge React needed for Server Actions and Next.js will opt you in into that runtime automatically.
For internal contributors, it means that we now run a compiler for 10 subparts of Next.js:
- next_bundle_server
- next_bundle_pages_prod
- next_bundle_pages_turbo
- next_bundle_pages_dev
- next_bundle_app_turbo_experimental
- next_bundle_app_prod
- next_bundle_app_prod_experimental
- next_bundle_app_turbo
- next_bundle_app_dev_experimental
- next_bundle_app_dev
### Simplified require-hook
Since the versions of React are correctly re-routed at build time for app pages, we don't need the require hook anymore
### Turbopack changes
The bundling logic in Turbopack has been addressed to properly follow the new logic
### Changes to the shared contexts system
Some context files need to have a shared instance between the rendering runtime and the user code, like the one that powers the `next/image` component. In general, the aliasing setup takes care of that but we need the require hook for code that is not compiled to reroute to the correct runtime. This only happens for pages node_modules.
A new Turbopack resolving plugin has been added to handle that logic in Turbopack.
### Misc changes
- `runtime-config` (that powers `next/config`) has been converted to an `.external` file, as it should have been
- there are some rules that have been added to the aliases to support the usage of `react-dom/server` in a server-components. We can do that now since the runtime takes care of separating the versions of React.
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Some tests may depend on `latest` to help us catch problems earlier. This adds support for the `resolutions` field for tests to allow pinning of deps that may be problematic upstream.
Sebastian "Sebbie" Silbermann