Enabling `experimental.isolatedDevBuild` required many changes to the
current workflow, so we will incrementally roll out to the tests.
Enabling on test-prod instead of test-experimental-prod 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.
1. ~~test-experimental-dev
([link](https://github.com/vercel/next.js/pull/84099))~~
2. test-dev ([link](https://github.com/vercel/next.js/pull/84562))
3. test-prod (here)
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
The experimental flag `reactDebugChannel` is currently off by default.
To avoid regressions in the debug channel integration, we enable the
flag for the experimental test shards.
We are preparing to enable `clientSegmentCache` by default on canary. To
prepare, this splits it into a separate CI runner and adds a failing
test manifest so we can incrementally migrate / fix failing tests before
stable release.
`experimental.ppr` is being superseded by `experimental.cacheComponents`
and will not exist in the form that is currently being tested in CI.
This frees up these CI resources until we delete the standalone PPR
flag. `cacheComponents` is tested via the experimental runners.
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...
1. Added functionality to change the package name in the rspack release
CI.
2. Fixed a bug in the get_resolve method of the NextExternalsPlugin.
3. Prepared the @next/rspack-core for the 1.0.0 version release.
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?
Added a new `rspack` directory as an independent Rust and pnpm
workspace, dedicated to building Next.js Rspack bindings. It shares code
with Turbopack through the `next-taskless` crate.
### What?
The benchmark is very broken:
* It doesn't await the run_once, so the code never runs
* project_path is incorrect so it doesn't find routes
* The returned Duration is never used as divan doesn't support custom benches
* `hmr_update` doesn't wait for an HMR update to happen as it just returns "no update"
* It uses `"next": "^15.0.0"` so JS and Rust code are incompatible with each other
It's easier to remove the benchmark than to fix it. It never worked anyway.
Eventually we probably want a e2e benchmark running next.js anyway.
Following up on https://github.com/vercel/next.js/pull/83240
When using ESM syntax in `next.config.ts` on a CJS project, Node.js
first assumes it as CJS, then parses it into ESM again, giving a
warning:
```
(node:27529) [MODULE_TYPELESS_PACKAGE_JSON] Warning: Module type of file://.../next.config.ts is not specified and it doesn't parse as CommonJS.
Reparsing as ES module because module syntax was detected. This incurs a performance overhead.
To eliminate this warning, add "type": "module" to .../package.json.
```
Therefore, give users the option to use `next.config.mts` which Node.js
expects ESM syntax.
The tests are a copy of `next-config-ts-native-ts` and only renamed the
config to mts.
---------
Co-authored-by: Sebastian "Sebbie" Silbermann <sebastian.silbermann@vercel.com>
Next.js tests are grouped based on timing data to better distribute them
for parallelization.
Previously this relied on a gist file that we would write to in CI.
However, this has more recently started resulting in 401s.
The actual reason for the 401s is the Turbo task wasn't propagating the
required environment variable to the task. It was mostly working by
accident, because we would store timing data on disk for the runner,
which would have been satisfied by a job that ran before it.
However despite that, relying on a gist file to read/write timing data
didn't feel like the write abstraction. I decided to refactor it to use
KV instead.
This also makes the handling more resilient to missing timing data. We
shouldn't fail the build if we can't fetch timings, as there's already
handling to fallback to round robin.
The `build-and-test` workflow runs on `canary` are currently annotated
with the following error
([x-ref](https://github.com/vercel/next.js/actions/runs/17629372493)):
```
Error when evaluating 'strategy' for job 'test-rspack-production'. .github/workflows/build_and_test.yml (Line: 412, Col: 13): Matrix exclude key 'react' does not match any key within the matrix
```
This addresses the issue for `test-rspack-production`, and also fixes
inconsistencies in other jobs regarding the handling of this matrix
dimension.
### What?
Adds proxy configuration support for e2e deployment tests, allowing test
traffic to be routed through a specified proxy server.
### Why?
Some testing environments require network traffic to be routed through
specific proxy servers or load balancers. This change enables the e2e
deployment test infrastructure to support such configurations by:
- Allowing specification of a proxy IP address via the
`NEXT_TEST_PROXY_ADDRESS` environment variable
- Automatically managing `/etc/hosts` entries to route deployment
domains through the proxy
- Providing proper cleanup when tests complete
### What?
Optimize CI workflow performance by moving e2e test project reset to a
weekly cron schedule and increasing deploy test parallelization.
### Why?
The current workflow runs project reset on every deploy test execution,
making parallel investigations by manual dispatch impossible.
Additionally, deploy tests were limited to 6 parallel groups, creating a
bottleneck.
### How?
- Created new weekly cron workflow (`test_e2e_project_reset_cron.yml`)
that runs every Sunday at 5AM UTC
- Removed inline project reset step from deploy test workflow
- Increased deploy test matrix from 6 to 8 parallel groups for faster
execution
- Added manual workflow dispatch option for emergency resets
Replaces and closes https://github.com/vercel/next.js/pull/78058
Closes PACK-4324
Before, you got duplicate modules because
`transition_to_client(postcss(webpack(source in rsc)) != postcss(webpack(transition_to_client(source in rsc))`
Now, we have:
```
rsc layer
--ESM import->
CSSModuleAsset(in rsc, contains raw SCSS source)
--CssReferenceSubType::Inner->
CssAsset(first in client layer, then processed with Webpack loader)
```
This aligns it with when you import CSS from a client component, in both cases the CSS module is first transitioned into the client layer, and then processed with Webpack
Before:
Cron runs would open a Draft PR if they happened to run before
deployment tests finished. Once deployment tests completed, the system
would either open a PR and immediately close it (if tests failed) or
open it as ready for review (if tests passed).
After:
Both cron runs and new releases will open Draft PRs. Once deployment
tests run and pass, these PRs will be marked as ready for review. If
tests fail, the PRs remain as drafts.
Related PRS:
https://github.com/vercel/v0/pull/12992https://github.com/vercel/front/pull/50036
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 stale bot comment says 2 years even though its 1.5 years (or 545
days to be precise).
The exact amount of time is not as important in this message so we can
remove it to avoid drift between the message and actual stale time.
### What?
Introduces a testing infrastructure to validate Next.js behavior with
the experimental Cache Components feature (`dynamicIO`) enabled. This PR
adds dedicated CI jobs and configuration to run a subset of existing
tests with Cache Components activated.
This has 271 more disabled test suites than the Legacy PPR test suite
manifest. The expectation is that we will be resolving the test failures
in followup PRs.
### Why?
Cache Components (dynamicIO) represents a significant architectural
change in how Next.js handles component caching and rendering. To ensure
a smooth transition when this becomes the default behavior, we need to:
1. **Validate compatibility** - Ensure existing applications continue to
work correctly when Cache Components is enabled
2. **Identify edge cases** - Catch potential issues early by running
tests in this new mode
3. **Build confidence** - Provide a safety net for the eventual
migration to Cache Components as the default
The manifest-based approach allows us to incrementally expand test
coverage as we fix compatibility issues, rather than attempting to run
all tests at once which would be overwhelming and block progress.
### How?
- **Test manifest** (`test/cache-components-tests-manifest.json`):
Defines which tests to run and tracks known failures that need
addressing
- **CI workflow changes**: Adds three new job groups that mirror
existing test jobs but with Cache Components enabled:
- `test-cache-components-integration`
- `test-cache-components-dev` (parallelized across 6 groups)
- `test-cache-components-prod` (parallelized across 7 groups)
- **Conditional feature activation**: When
`__NEXT_EXPERIMENTAL_CACHE_COMPONENTS=true` is set during testing,
`dynamicIO` is automatically enabled unless explicitly disabled
- **Test adjustments**: Updates error message expectations in tests to
handle the different environment label ("Prerender" vs "Server") when
Cache Components is active
The infrastructure is designed to be temporary and will be removed once
Cache Components becomes the default behavior.
NAR-172
This change adds a check to ensure the front sync workflow is enabled
before attempting to trigger it. Previously, when the workflow was
disabled, the dispatch would fail and cause false alerts about
deployment test failures.
Now, if the workflow is disabled, the sync trigger is skipped with clear
logging. The on-call person should be aware that the workflow is
disabled and can manually rerun the sync once the workflow is
re-enabled.
I tested this by commenting out the tests and just running the check if
workflow is enabled step and it worked:
Jiwon Choi