The `scripts/install-native.mjs` script is run in the postinstall step
of the Next.js monorepo to install the published binary packages of the
latest Next.js canary version. This change makes the script respect the
`NEXT_TEST_PREFER_OFFLINE` environment variable, allowing it to prefer
installing previously downloaded packages from the local cache. This is
useful for scenarios where network access is limited or unavailable.
This PR extracts the existing git change detection logic from the `get-changed-tests` script into a separate module. This allows reusing the same logic in the `run-for-change` script, ensuring consistent behavior across the two scripts to determine changed files. Specifically, this ensures that in stacked PRs, the docs-only change detection (and the test-only change detection in the upstack PR) works correctly by diffing against the appropriate base branch.
I don't know what this script does, but it compiles with the workspace's version of reqwest, and that reduces the copies of reqwest we pull in.
Might slightly speed up cold builds of the entire workspace.
Libraries that want to support Next.js without specific public adaptors
must use dynamic requires and other non-standard tricks to conditionally
load Next.js specific behavior. To simplify this we are adding a
condition to Next.js so that package authors can load Next.js specific
versions of code publicly (through export maps) and privately (through
import maps).
The condition is added when cacheComponents is enabled. This will allow
libraries to target modern Next.js conditionally without publishing new
majors with a new floor version for optional peer dependencies on
Next.js. In the future this will be the only mode for Next.js and the
condition will always be present
The condition is currently only implemented for bundled code. We want to
support this for externals too but it is tricky because determining the
right condition requires running Node.js first and I want to be careful
about adding any process indirection that slows down cold start. This
will be addressed in a future update.
---------
Co-authored-by: Sebastian Sebbie Silbermann <[email protected]>
The peerDeps are already bumped to 19.2.0 at
https://github.com/vercel/next.js/pull/84463, but the test/CNA templates
weren't updated as the `syncPagesRouterReact` value is always false at
the moment, which blocked the update.
Therefore, remove the `syncPagesRouterReact` condition to match the
actual peerDeps bump.
---------
Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
Co-authored-by: Sebastian Sebbie Silbermann <[email protected]>
- update codemod script
- upgrade both release scripts, not sure which one is correct
<!-- 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
### 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 #
-->
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: JJ Kasper <[email protected]>
Flake detection runs changed test(s) 6 times: 3 in Webpack, 3 in
Turbopack. for the purposes of detecting flakes, and to reduce the
burden on CI, this runs flake detection only with Turbopack (esp. now
that it's enabled by default).
### Why?
This PR cleans up the incremental rollout of enabling `isolatedDevBuild`
throughout the CI, as it required many test changes (x-ref:
https://github.com/vercel/next.js/pull/84043).
- https://github.com/vercel/next.js/pull/84556
- https://github.com/vercel/next.js/pull/84558
- https://github.com/vercel/next.js/pull/84559
- https://github.com/vercel/next.js/pull/84562
This PR enables `experimental.isolatedDevBuild` by default so that users
can run `next dev` and `next build` in the same directory, and they
would not conflict. This occasionally happens when developing with AI
tools, where you have a running dev server, but the Agent runs `next
build`.
### How?
- Removed `__NEXT_EXPERIMENTAL_ISOLATED_DEV_BUILD` flag and its usage
from CI and tests
- Updated tests that were not caught via rollout (e.g., missed out on
test-*-windows)
- Moved `isolatedDevBuild` option out of experimental
- Added Telemetry
Will follow up with docs.
Reverts vercel/next.js#84389
Attempt number 3, #84374 fixed propagation of bundler environment variables to vercel cli operations, to ensure the test configuration is respected.
[Deployment Tests Run 1](https://github.com/vercel/next.js/actions/runs/18146684793/job/51649631635). A fair number of failures.
[Deployment Tests Run 2](https://github.com/vercel/next.js/actions/runs/18154875270). After #84395. These still have a set of failures, but i confirmed that the deployment builds are running `webpack`.
The tests that are failing are related to 'prefetches' (test/e2e/app-dir/segment-cache/prefetch-runtime/prefetch-runtime.test.ts and test/e2e/app-dir/segment-cache/prefetch-layout-sharing/prefetch-layout-sharing.test.ts) and generally the error is a timeout. Recent deployment runs for canary releases are also failing, but on different tests.
Trying again after #[84419](https://github.com/vercel/next.js/pull/84419). [Deployment Tests Run 3](https://github.com/vercel/next.js/actions/runs/18173375427). Failures appeared flaky, rerunning failures...
Reverts vercel/next.js#84348 which itself reverted #84216.
In the 2nd attempt to make --turbopack a default behavior.
* adjust the Generate Pull Request States action to specify `--webpack`
* set the `IS_WEBPACK_TEST` flag in the deployment e2e tests (which are now [passing](https://github.com/vercel/next.js/actions/runs/18113062122))
* make the warning about having a webpack config without a turbopack config more verbose and consistently an error
Make Turbopack the default bundler for Next 🚀
## What
Add a `--webpack` flag so users can select webpack
Change behavior so if neither `--turbopack` or `--webpack` is set we default to Turbopack.
If we have defaulted the build to turbopack and we observe that the user has a `webpack` config in their next config but no turbopack config, then we issue a warning about this being a potential problem, if this happens during `next build` the warning becomes an error and fails the build. The solution for users is just to explicitly set `--webpack` or `--turbopack`
There were a number of subtle issues
* some users directly set the `TURBOPACK` environment variable, this PR adds support for that though users should really be passing `--turbopack` so it will not be documented
* rspack is enabled via a plugin that sets an environment variable when loading next config, which means it happens way too late!
* For builds this isn't too bad, we just have to recompute the `Bundler` after loading the config. For `dev` the parent process can get out of sync with the child, but this is only really relevant for telemetry and for that we already load the config in the parent so just defer computing `isTurboSession`.
Most of this is about fixing package.json scripts and CI builds configs.
* For package.json
* i added aliases e.g. `test-dev` == `test-dev-webpack` but preserved the old names. In the long run we will want to remove the unsuffixed aliases
* this required some modifications to existing configs to ensure everything was setting the correct env variables
* For ci, i added a new `IS_WEBPACK_TEST` variable to a number of tests but preserved all names.
* Again, in the future it would make sense to rename ci jobs but that is deferred for right now.
* This also makes it clear that a set of tests scenarios (e.g. ppr, experimental, test-new-tests-*) never run with turbopack. This is not addressed right now but should be in the future.
## Why
Today, the default bundler for next is webpack but with turbopack becoming stable it is time to just ship it. Turbopack is already recommended for dev and builds. Create Next App also steers users towards Turbopack. According to telemetry we already have about 50% of all dev sessions and build adoption is growing. So fundamentally why are we even asking users to make a decision?
### What?
This PR fixes critical URL mutation issues in Next.js routing that were
causing state pollution between requests and breaking compatibility
between App Router and Pages Router during rewrite handling.
### Why?
Several interconnected problems were discovered in the routing system:
1. **URL Object Mutation**: The original `parsedUrl` objects were being
mutated during rewrite processing, causing state to leak between
requests and potentially affecting subsequent routing decisions.
2. **Router Type Confusion**: The routing system lacked explicit
tracking of whether a route belonged to the App Router or Pages Router,
leading to incorrect query parameter handling and normalization logic
being applied inconsistently.
3. **Query Parameter Pollution**: App Router RSC payloads were being
polluted with rewrite query parameters that should only be applied to
Pages Router routes, breaking the separation of concerns between the two
routing systems.
4. **Catch-all Route Normalization**: Pages Router catch-all routes
require specific array normalization (e.g., `["hello", "world"]`) but
this was being applied inconsistently or to the wrong router type.
5. **Middleware Filtering Bypass**: The x-matched-path header handling
was bypassing proper middleware query filtering in deployment scenarios.
These issues manifested as test failures where Pages Router catch-all
routes weren't receiving proper array values, App Router routes were
getting contaminated with rewrite parameters, and the routing behavior
was inconsistent between development and deployment environments.
### Dependant PR's
https://github.com/vercel/vercel/pull/13927
[NAR-398](https://linear.app/vercel/issue/NAR-398)
Retrying this...
## TODO
- [x] deploy docs action
- [x] verify that re-compiled deps are ok, no version regression
- [x] turbopack with fumadocs errors out, why?
The merge driver for `errors.json` has been around for a while, and
seems to work without issues. This PR enables it by default by
installing it in `postinstall`(via the existing `git-configure.mjs`
script which is invoked from there already)
It also adds `scripts/merge-errors-json/uninstall` to temporarily
disable it in case of issues. If the driver crashes, we'll also print
instructions on how to disable it.
What?
This PR updates the dependency "prettier" from version 3.2.5 to version
3.6.2. It also modifies other scripts by using the pnpm run prettier-fix
after updating the dependency.
Why?
This is updated to benefit from the changes and fixes introduced in the
newer versions of prettier, from versions 3.3 to 3.6.
How?
The package has been updated using pnpm install prettier@latest, and the
files other than package.json and pnpm-lock.json have been modified
using the script pnpm run prettier-fix.
This PR does only have formatting changes introduced by the updated
dependency
This PR is the same as #82719 , with fixes implemented to prevent
prettier to modifiy symlink files
The `patch-next.cjs` script is failing because two of its dependencies,
`pack-util` and `build-native`, are missing their CommonJS versions,
which are required for compatibility with the current Node.js
environment. To fix this, i added the transpiled `pack-util.js` and
`build-native.js` files.
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Co-authored-by: Benjamin Woodruff <[email protected]>
This creates a new workflow to create a release branch and apply the
necessary configs to allow releasing from that branch as this is quite
common for backports.
The git merge driver does not expect debugging messages to output on
stdout, and instead requires them to output on stderr. This changes the
`console.log` to a `console.error` to account for this requirement.
- Follow the naming conventions of other environment variables and prefix `TEST_WASM` with `NEXT_TEST_WASM` so that there's less chance of conflicts with user code
- Remove the logic in `setup-wasm.mjs` that modifies the repository (not great for running tests locally) and instead try to match the environment-variable-override behavior used for native (non-wasm) bindings via `NEXT_TEST_WASM_DIR`.
- Hard-fail if `NEXT_TEST_WASM` is set and we fail to load wasm bindings instead of silently using fallback logic that loads native bindings instead.
- We don't need to install `wasm-pack` with `curl | sh` for tests: `pnpm` already installs it (and pins a specific version).
- The whole dance of renaming the directory from `pkg` to `pkg-nextjs` is a hack we use when publishing the package, as we're building both "web" and "nextjs" targets. We don't need to do that for tests.
- Fix handling of `undefined` values in SWC options objects.
- Remove hacks for Next v12.2
Adds a merge driver that can automatically re-number messages added to
`errors.json` if a merge conflict occurs. Now, it would be easier to
just run `pnpm update-error-codes`, but that's slow and requires
installing deps + building everything, so i'm just manually merging +
renumbering instead.
To avoid disrupting people's workflows (in case this is buggy, or
something), it's currently *not enabled by default*. To enable the merge
driver, run:
```shell
scripts/merge-errors-json/install
```
which will add it to your `.git/config`. Once it's been confirmed to
work well, we can make this command run by default in `postinstall`.
### Testing
Other than the test i added (which doesn't run git), i've tested this
manually with this script that rebases some stacked branches:
<details>
<summary>merge-driver-test.sh</summary>
```bash
#!/usr/bin/env bash
set -eu -o pipefail
cd "$1"
current_branch="$(git branch --show-current)"
(
set -eu -o pipefail
git switch lubieowoce/errors-json-merge-driver
git switch --force-create 'test/errors-json/base'
echo '{
"1": "base message"
}
' > packages/next/errors.json
git commit -am 'base commit'
git switch --force-create 'test/errors-json/one';
echo '{
"1": "base message",
"2": "message from branch one"
}
' > packages/next/errors.json
git commit -am 'commit 1'
git switch 'test/errors-json/base'
git switch --force-create 'test/errors-json/stacked-1'
echo '{
"1": "base message",
"2": "message from stacked 1"
}
' > packages/next/errors.json
git commit -am 'stacked 1'
git switch --force-create 'test/errors-json/stacked-2'
echo '{
"1": "base message",
"2": "message from stacked 1",
"3": "message from stacked 2"
}
' > packages/next/errors.json
git commit -am 'stacked 2'
git rebase 'test/errors-json/one' --update-refs || true
bat packages/next/errors.json
git rebase --abort || true
)
git switch "$current_branch"
```
</details>
The script does a bunch of git operations, so it's easiest to put it
outside of your next.js repo and call `bash merge-driver-test.sh
path/to/next.js`.
When the "Version Packages" PR is merged, the created commit is the
format of "Version Packages (#number)". Therefore, the
check-is-release.js script won't match the current regex. Also, I
modified the workflows that use the `check-is-release.js` to consider
the new release as a release workflow as well.
### Why?
When backport releases are published, they are marked as `latest` dist
tag, which makes `next@latest` not the "latest."
x-ref: [slack
thread](https://vercel.slack.com/archives/C04LGE5SYEB/p1747984846615469)
### How?
Use `stable` dist tag for backports.
### Why?
The `process.env.RELEASE_TYPE` handling was set incorrectly. It
should've been set to the "trigger" workflow, but instead, it was set to
the "publish" workflow. Therefore, the "publish" workflow needs to know
which dist tag to set for publish.
---------
Co-authored-by: Sebastian Sebbie Silbermann <[email protected]>
PR https://github.com/vercel/next.js/pull/79596 introduced setting
`stable` dist tag for backports, but due to
https://github.com/vercel/next.js/pull/79538#pullrequestreview-2866854431,
> This sounds like something users would use. However, it might point to
14.x when 15.x exists and we would certainly want people to use 14.x.
It's also weird that 14.x would have a `stable` tag but not 15.x.
>
> That's why `backport` makes more sense since it's less specific and
not common vernacular when talking about release characteristics (e.g.
"experimental", "nightly", "stable", "unstable" etc.).
>
> The tag could actually just be "internal-backport" and ideally we'd
remove it right after publish. The goal here isn't to come up with a
useful tag for backports. We just want to work around NPM requiring a
tag during publish.
better to use another dist tag: i.e.,`backport`.
### Why?
If the current version is less than the latest, it means this is a
backport release. Since NPM sets the `latest` tag by default during
publishing, when users install `next@latest`, they might get the
backported version instead of the actual "latest" version. Therefore, we
explicitly set the tag as `stable` for backports.
