## Summary
Renames the CI job display names from 'Test new tests' to 'Test new and
changed tests' to accurately reflect what these jobs do.
The `get-changed-tests.mjs` script uses `git diff --name-only` which
detects both added and modified files, so the job names should reflect
that they test both new AND changed test files.
This applies fixes for outputs in `onBuildComplete` with various slight
differences from expected values. This also applies some fixes in the
route-module interface to ensure we install the process handlers for PPR
since currently that was done in `next-server` which we want to get rid
of and there was an edge case with query parsing logic in the
route-module.
Our E2E tests were run against this here to validate
https://github.com/vercel/next.js/actions/runs/21324578779 and failures
are matching existing failures on canary.
x-ref: https://github.com/nextjs/adapter-vercel/pull/11
x-ref: https://github.com/vercel/vercel/pull/14574
---------
Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
The recent change to always run all tests without aborting on failure
(#88435) inadvertently broke manifest generation. Previously, test
output was emitted for all tests when `NEXT_TEST_CONTINUE_ON_ERROR` was
set, but that variable was removed. Now test output is only emitted for
failing tests, causing the manifest to lose all passing test entries.
This adds a new `NEXT_TEST_EMIT_ALL_OUTPUT` environment variable that
restores the full output behavior specifically for the manifest
generation workflows.
Part of https://linear.app/vercel/issue/NAR-719/
We previously only supported a single manifest for filtering tests. However, Cache Component deploy tests have two manifests. Now we merge manifests append-only.
## Test plan
- [x] https://github.com/vercel/next.js/pull/88821 adds a failed deploy test to a test suite also listed in the CC manifest. Tests from CC and deploy manifest are skipped
```console
$ NEXT_EXTERNAL_TESTS_FILTERS="test/deploy-tests-manifest.json,test/cache-components-tests-manifest.json" NEXT_TEST_MODE=deploy node run-tests.js -c 1 --retries 0 test/e2e/app-dir/searchparams-reuse-loading/searchparams-reuse-loading.test.ts
○ skipped should re-use loading from "full" prefetch for param-full URL when navigating to param-less route
○ skipped should re-use loading from "full" prefetch for param-less URL when navigating to param-full route
○ skipped should re-use loading from "full" prefetch for param-full URL when navigating to param-full route
when aliasing is skipped
✕ should work for not found pages
✕ should work for route handlers
✕ should work for navigating to pages dir
Without Middleware
✕ should correctly return different RSC data for full prefetches with different searchParam values
With Middleware
○ skipped should correctly return different RSC data for full prefetches with different searchParam values
```
Fixes a regression from #85981 where manual deploy tests with custom
tarball URLs incorrectly trigger retries and Slack notifications. Now
only release-triggered runs and manually-triggered canary tests are
retried/reported.
It's more useful and efficient to run all tests and report all failures
instead of aborting on the first failure. This way, developers get a
complete picture of what needs to be fixed in a single run, and don't
have to go through multiple iterations of fixing one failure at a time.
## What?
Adds the docs-only change check to the `stats-aggregate` job.
## Why?
The `stats` job already skips work for docs-only changes using
`scripts/run-for-change.mjs`, but the `stats-aggregate` job was missing
this check. This caused unnecessary job runs when PRs only contain
documentation changes.
## How?
- Added the "Check non-docs only change" step (same pattern as the
`stats` job)
- Added conditional `if` checks to all subsequent steps
- Changed `fetch-depth` from 1 to 25 (required for the change detection
script to check commit history)
## Summary
- Add push trigger for canary branch to `pull_request_stats.yml`
- Remove redundant `releaseStats` job from `build_and_deploy.yml`
- Rename workflow/jobs from "PR Stats" to "Stats"
## Background
The stats system was designed to save historical metrics to KV for trend
tracking, but it wasn't working:
1. `releaseStats` job only ran on actual stable releases (rare)
2. When it did run, KV secrets were missing
3. PR stats had KV secrets but didn't save (because `isRelease=false`)
This change consolidates stats into one workflow that runs on both PRs
and canary pushes.
## Behavior
**For PRs:**
- Compare PR branch vs canary HEAD
- Post comment to PR
- Don't save to KV
**For canary pushes:**
- Compare current canary vs last stable release tag
- Post comment to the commit
- Save stats to KV for historical trend tracking
## Test plan
- [ ] Verify workflow triggers on PR (existing behavior)
- [ ] Verify workflow triggers on canary push (new behavior)
- [ ] Verify stats are saved to KV on canary push
- [ ] Verify trend sparklines appear in PR comments (once history builds
up)
## Summary
Comprehensive improvements to the PR stats action for more reliable benchmarks and reduced CI noise.
### Vercel KV Integration
- Add `@vercel/kv` for historical data persistence
- Track metrics over time with `loadHistory()` / `saveToHistory()`
- Display trend sparklines in comments when history is available
### Comment Generation Refactor
- New `METRIC_LABELS` and `METRIC_GROUPS` configuration system
- Organized metrics by category (Dev Server, Production Builds, Production Runtime)
- Better formatting utilities (`prettifyTime`, `formatChange`, `generateTrendBar`)
- Bundle group totals for KV persistence
### Noise Reduction
- Significance thresholds: `50ms AND 10%` for time, `1KB AND 1%` for size
- Additional `<2%` filter for long-running operations (builds)
- Filters typical CI variance while catching real regressions
### Stats Config Updates
- Add `measureDevBoot: true` to enable dev boot benchmarks
- Fix `appDevCommand` to include `dev` subcommand
- Add `--webpack` flag to `appBuildCommand`
- Rename "Client Bundles (main, webpack)" to "Client Bundles (main)"
- Add `turbopack: {}` to test configs
### GitHub Actions Updates
- New `action.yml` with bundler input parameter
- Workflow improvements in `pull_request_stats.yml`
### New Files
- `scripts/test-stats-benchmark.sh` - Local testing script
- `.github/actions/next-stats-action/src/util/stats.js` - Shared stats utilities
- `.github/actions/next-stats-action/test-local.js` - Local comment testing
## Test Plan
```bash
cd .github/actions/next-stats-action
node test-local.js # Basic test
node test-local.js --with-history # Test with trend sparklines
```
## Summary
Fixes flaky jscodeshift codemod tests on Windows CI (e.g.,
`next-async-request-api-dynamic-apis.test.js`,
`built-in-next-font.test.js`, `new-link.test.js`).
### Problem
Windows CI runners have `core.autocrlf=true` by default, which causes
test failures because:
1. Fixture files get checked out with CRLF line endings
2. jscodeshift's printer (recast) outputs CRLF on Windows
3. String comparison fails between expected and actual output
### Solution
Patches jscodeshift's test utilities in `jest-setup-after-env.ts`
(Windows only) to normalize line endings:
```typescript
const normalizeLF = (str: string) =>
str
.replace(/\r\n/g, '\n') // CRLF → LF
.replace(/[ \t]+$/gm, '') // Remove trailing whitespace per line
.replace(/\n*$/, '\n') // Ensure exactly one trailing newline
```
**Key changes:**
- **Patches `runInlineTest`** - Normalizes input, runs transform,
normalizes output, then compares
- **Patches `defineTest`** - Reads fixtures with normalization, uses
patched `runInlineTest`
- **Handles closure issue** - jscodeshift's internal functions use
closures that bypass exports, so we replace the functions entirely
Also includes a belt-and-suspenders `sed` command in the workflow to
strip CRLF from source files.
### Why not just fix `.gitattributes`?
The `.gitattributes` `eol=lf` setting helps, but doesn't solve the
problem because:
1. jscodeshift's recast printer uses platform-native line endings when
generating output
2. Fixture files may have inconsistent trailing whitespace/newlines
3. Self-hosted Windows runners may have different git configurations
### Follow-up
**TODO:** Configure Windows self-hosted runners with `git config
--system core.autocrlf false` so the `sed` workaround can be removed.
See the `TODO` comment in `build_reusable.yml`.
## Test Plan
- Windows CI unit tests should pass consistently
- Normalization only runs on Windows (`process.platform === 'win32'`)
- Other platforms unaffected
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
When we fixed deploy tests to consistently run with the explicitly
provided Next.js release version, it broke this job which was relying on
an explicit match on the "test e2e deploy canary" string.
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.
Proxy is not being picked up during prod on Windows. It is because of
two reasons:
1. `isAtConventionLevel` condition was false as the dir was `\\` in
Windows, but was checking with explicit `/`.
2. `page` value passed to `getStaticInfoIncludingLayouts` function was
in `\\proxy` but was expected to be `/proxy`, which is later used for
`isProxy` condition.
Therefore, the given paths needed to be normalized.
Current behavior:
https://github.com/vercel/next.js/actions/runs/18872127141/job/53853048061?pr=85443#step:34:160
Closes NEXT-4756
<!-- 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 #
-->
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.
When deploy tests run on release branches, they end up using "canary"
rather than the version associated with the release. This means that the
test files might be misaligned with the underlying versions they are
testing.
We are already doing the work of collecting the next version, we just
weren't plumbing it into `NEXT_TEST_VERSION`.
- 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 <jj@jjsweb.site>
Using Node.js native TS resolution is great. However, enabling by
default can be frustrating for the users as it has restrictions, such as
requiring a file extension for imports, and does not read tsconfig.json
(no import alias).
It also emits a warning when using `next.config.ts` on a CommonJS
project, which is the majority of the apps:
```
(node:68710) [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.
(Use `node --trace-warnings ...` to show where the warning was created)
```
Therefore, put this under an `--experimental-next-config-strip-types`
flag for now.
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
### 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.
This enables `experimental.clientSegmentCache` by default and the
additional CI resources associated with testing it independently.
There were a few remaining test failures that are individually disabled
with `TODO(client-segment-cache)` markers. We can fix forward as they
are small optimizations rather than anything blocking release.
In a follow-up PR, we'll fully remove the dead code associated with the
`clientSegmentCache: false` case.
@lukesandberg pointed out that we have test flakes from too many file descriptors open.
I think we should significantly raise these limits on the ci runners (@ijjk?), but given that we run 8 tests in parallel, it's probably good anyways for Turbopack to be less aggressive with file IO in our CI.
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
Enabling `experimental.isolatedDevBuild` required many changes to the
current workflow, so we will incrementally roll out to the tests.
Enabling on test-integration instead of test-experimental-integration
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))
2. test-prod ([link](https://github.com/vercel/next.js/pull/84556))
3. test-integration (here)
4. test-unit
5. Enable by default, remove the flag, and update the rest
x-ref: https://github.com/vercel/next.js/pull/84043
Tim Neutkens