🔄 Sync from upstream - 2026-01-08#133
Merged
lakshit-hivel merged 60 commits intocanaryfrom Jan 8, 2026
Merged
Conversation
…idation (vercel#88069) ## Summary Fixes a bug where calling `revalidateTag(tag, profile)` incorrectly triggers client-side cache invalidation, causing read-your-own-writes behavior that violates stale-while-revalidate semantics. ### The Problem When `revalidateTag('tag', 'max')` is called in a server action: 1. The tag is correctly marked for stale-while-revalidate 2. BUT the `x-action-revalidated` header is incorrectly set to `1` 3. This triggers client-side cache invalidation via `revalidateEntireCache()` 4. The client navigates and may display stale data from background revalidation This caused the confusing behavior where: - Click 1: Nothing happens (correct) - Click 2: Nothing happens (correct) - Click 3: Data changes to a stale value from click 1 (incorrect!) ### The Fix In `addRevalidationHeader`, change the `isTagRevalidated` calculation to only count tags **without** a profile (from `updateTag`). Tags with a profile (from `revalidateTag`) should follow stale-while-revalidate semantics and not trigger immediate client-side cache invalidation. ```typescript // Before: const isTagRevalidated = workStore.pendingRevalidatedTags?.length ? 1 : 0 // After: const isTagRevalidated = workStore.pendingRevalidatedTags?.some( (item) => item.profile === undefined ) ? 1 : 0 ``` ### Expected Behavior After Fix | API | Profile | Header Set | Client Behavior | |-----|---------|------------|-----------------| | `updateTag(tag)` | `undefined` | ✅ Yes | Immediate refresh (read-your-own-writes) | | `revalidateTag(tag, 'max')` | `'max'` | ❌ No | Keep stale data (SWR) | | `revalidateTag(tag, { expire: 0 })` | `{ expire: 0 }` | ✅ Yes* | Immediate refresh | *For immediate expiration via `pathWasRevalidated` which is already handled correctly. ## Test Plan - [x] Added new test page at `test/e2e/app-dir/use-cache/app/(partially-static)/revalidate-tag-no-refresh/page.tsx` - [x] Added test case that verifies 3 clicks of `revalidateTag` with profile don't change the displayed value - [x] Verified existing `updateTag` test (`should update after revalidateTag correctly`) still passes - [x] Verified both tests pass with `pnpm test-start` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
i got bit by this often :p <!-- 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 # -->
…cel#87988) - redesigns the default global + default error boundaries. removing the WSOD forever :/ - adds dark mode support - unifies a bit of the styling - add the digest for the server error - adds a return button on the client errors <img width="3328" height="1914" alt="CleanShot 2026-01-02 at 09 46 36@2x" src="https://github.com/user-attachments/assets/9994eb37-c22b-4847-9a18-e9acf0ae6236" /> <img width="2144" height="1242" alt="CleanShot 2026-01-02 at 09 47 01@2x" src="https://github.com/user-attachments/assets/9b3bcf39-63f6-4c8d-85c5-2976c25f5b7b" /> <img width="2238" height="1632" alt="CleanShot 2026-01-02 at 09 47 17@2x" src="https://github.com/user-attachments/assets/436433d7-9873-496a-9c96-536e070be9d7" /> <img width="1708" height="1260" alt="CleanShot 2026-01-02 at 09 47 23@2x" src="https://github.com/user-attachments/assets/1ec42402-dbd9-41a3-801b-4745a4f128f7" /> --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
adding basic config with graphite/repo instructions <!-- 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 # -->
) ## Summary Reduces flakiness in the OpenTelemetry e2e test (`test/e2e/opentelemetry/instrumentation/opentelemetry.test.ts`) for production mode. ### Root Cause In production mode, Next.js generates additional spans from: - RSC prefetch requests (with `?_rsc` query param) - Edge runtime boundary spans These extra root spans cause `toMatchObject` assertions to fail because they receive more spans than expected. ### Changes 1. **Filter spans by expected `http.target`** in `expectTrace()`: - Extract expected `http.target` values from the match object - Filter root spans to only include those with matching targets - This excludes RSC prefetch and edge boundary spans that aren't part of the test assertion 2. **Fix TestExporter callback bug** in `instrumentation-test.ts`: - The success callback was called unconditionally (even after errors) - Added early `return` after error callback - Moved success callback inside the success path ## Test Plan - [x] All 34 tests pass in production mode (`NEXT_TEST_MODE=start`) - [ ] CI passes
…ilds (vercel#86554) When we landed vercel#76207 we started propagating the `stale-while-revalidate` value to RSC responses. We wanted a way to express to CDNs that it can keep serving the cached content for some time while a revalidation runs in the background, but we specifically don't want that for private caches. As a result of this header, when re-building your application locally (or doing something on the server that would have expired the cache), the browser's disk cache would serve a stale RSC response. We currently encode a buildId in RSC payloads, so the client router will discard RSC responses that don't match what it is expecting. Unfortunately there isn't a `s-stale-while-revalidate` header to express the intended semantics. This moves the `stale-while-revalidate` configuration into the `CDN-Cache-Control` header, which is becoming standardized and is supported by a wide variety of CDNs. This allows us to specify the SWR behavior more explicitly to CDNs while not impacting private caches like the browser. It restores the previous behavior of only setting `s-maxage` on the `cache-control` itself to avoid influencing browser cache. If Next.js is deployed to a CDN that doesn't support this header, it can be customized via `nextConfig.experimental.cdnCacheControlHeader`. Eg, if deployed to Fastly, you'd configure this to `cdnCacheControlHeader: 'Surrogate-Control'`. Closes NAR-525 Reference docs: [Vercel](https://vercel.com/docs/headers/cache-control-headers#cdn-cache-control-header) [Cloudflare](https://developers.cloudflare.com/cache/concepts/cdn-cache-control/) [Fastly](https://www.fastly.com/documentation/reference/http/http-headers/Surrogate-Control/) [RFC 9213](https://httpwg.org/specs/rfc9213.html)
Ensure that turbopack produces sourcemaps with the `names` field populated. SWC has support for this but because we are using lower level APIs we need to collect identifiers ourself. This follows the pattern that SWC uses internally in APIs like `Compiler::optimize`. Partially addresses vercel#87896, to actually use these when reporting errors we need to modify the deobfuscation logic in next. <!-- 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 # -->
### What? It's a VecDeque and we are calling pop_front() so we don't want to reverse the roots
…pp Router (vercel#87389) Flagged behind `experimental.strictRouteTypes`. Most notably this disallows `void`. We generally treat `void` as "forgot to add return" in React e.g. ```tsx async function Page() { <div />; } ``` which is a common beginner mistake. The downside is that this breaks unconditional `notFound()` or `redirect()` in Next.js. Those function throw but even with `never` as a return type, [TypeScript will not infer that this causes the caller to return `never` as well](microsoft/TypeScript#26537). ```tsx // implicit `void` return type instead of `never` due to calling `notFound(): never` function Page() { notFound() } ``` The fix is to explicitly annotate unconditional `notFound` usage: ```tsx function Page(): never { notFound() } ``` Conditional usage would already have another `return` statement. If that's missing still, we'd consider this a mistake. You can always do `return` without a value to fix the type-issue. Pages in Pages Router are not affected. Tightening types for Pages Router is out-of-scope for this project. Closes https://linear.app/vercel/issue/NXT-127/
…oute modules (vercel#87398) Reverts vercel#83239 flagged behind `experimental.strictRouteTypes`. Makes the error messages a bit friendlier since we no longer need these `__*` helper types which made it harder to grok what we were actually doing. `satisfies` is available since TypeScript 4.9. Our lowest supported version is 5.1. We could land this unflagged but this just makes it clearer that all the type changes are behind a single flag instead of being spread across flagged and unflagged. Closes https://linear.app/vercel/issue/NXT-128
## Summary Development scripts for profiling and benchmarking Next.js dev server boot time. ### Benchmarking Scripts - `benchmark-boot-time.sh` - Wall-clock benchmarking with two metrics: - **Listen time**: When TCP port accepts connections - **Ready time**: When first HTTP request succeeds - `benchmark-next-dev-boot.js` - Multi-iteration benchmarking with statistics (median, p95, stddev) ### Profiling Scripts - `profile-next-dev-boot.js` - CPU profiling infrastructure using V8 inspector - `analyze-profile.js` - Analyze CPU profiles to identify hot modules by CPU time ### Analysis Scripts - `analyze-dev-server-bundle.js` - Bundle analyzer for dev server (generates treemap report) - `trace-cli-startup.js` - Module loading trace to identify slow imports ## Usage ```bash # Benchmark dev server boot time (5 runs by default) ./scripts/benchmark-boot-time.sh # Multi-iteration benchmark with stats node scripts/benchmark-next-dev-boot.js --iterations 10 # Generate CPU profile node scripts/profile-next-dev-boot.js # Analyze profile output node scripts/analyze-profile.js .next/cpu-profiles/*.cpuprofile # Analyze dev server bundle node scripts/analyze-dev-server-bundle.js --open ``` ## Test Plan - [x] Run `./scripts/benchmark-boot-time.sh` locally - [x] Verify scripts execute without errors
) ## 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 ```
…sizeLimit` when validating route (vercel#87633) Not flagged behind `experimental.strictRouteTypes`. This is just a bug fix. Got revealed once we typechecked routes in pure Pages Router apps e.g. ``` .next/types/validator.ts:76:11 Type error: Type 'typeof import("~/pages/api/hello")' does not satisfy the expected type 'ApiRouteConfig'. The types of 'config.api.bodyParser' are incompatible between these types. Type 'false | { sizeLimit?: SizeLimit; }' is not assignable to type 'boolean | { sizeLimit?: string; }'. Type '{ sizeLimit?: SizeLimit; }' is not assignable to type 'boolean | { sizeLimit?: string; }'. Type '{ sizeLimit?: SizeLimit; }' is not assignable to type '{ sizeLimit?: string; }'. Types of property 'sizeLimit' are incompatible. Type 'SizeLimit' is not assignable to type 'string'. Type 'number' is not assignable to type 'string'. ``` -- https://github.com/vercel/next.js/actions/runs/20427462435/job/58690778302?pr=87628#step:32:562 Closes https://linear.app/vercel/issue/NXT-121
Reverting since it produced merge conflicts with in-progress [strict-route-types project](https://linear.app/vercel/project/nextjs-strict-route-types-2f0a70110d5d/overview): The lesson learned from the earlier PR was that this is a risky change. We'll land a similar change flagged in vercel#87768
…d even if .next is excluded (vercel#87768) Flagged behind `experimental.strictRouteTypes` This fixes issues where cache profiles where not included or routes not validated if `.next` was excluded to squeeze out every bit of TypeScript performance. It also fixes a redundant type-check since we have separate dev and prod dist folders. If you run `next dev` and (`next build` or `next typegen`), you'd type-check routes and links twice. Now `next-env.d.ts` only exists once where we decide which dist folder to type-check. Going forward, new Next.js type-checking should be added to `next-env.d.ts`. That file is fully controlled by Next.js and churning it, does not churn users since it's not in version control. `next-env.d.ts` will be moved into `.next` in a follow-up. Ideally independent of the dist folder i.e. independent of `next dev` vs `next build`. Closes https://linear.app/vercel/issue/NXT-124/ vercel#87319 but flagged.
This auto-generated PR updates the production integration test manifest used when testing Rspack.
This auto-generated PR updates the development integration test manifest used when testing Rspack.
Using `taint` APIs from React without enabling `experimental.taint` will error at runtime because it needs to bundle experimental React, making it hard to catch and potentially leading to downtime. This updates our transform to throw an error if we detect that it's imported but `taint` isn't enabled. Fixes NAR-690
…8116) ## What? Adds [Conductor](https://www.conductor.build/) configuration to enable team members to use parallel Claude Code agents for Next.js development. **Files added:** - `.conductor/conductor.json` - Main configuration with setup/run scripts - `.conductor/README.md` - Documentation for using Conductor with Next.js - `.gitignore` - Added entry to ignore Conductor worktree directories ## Why? Conductor is a Mac app that orchestrates multiple Claude Code agents in parallel, each with its own isolated git worktree. This enables: - **Parallel development** - Work on multiple features simultaneously without branch conflicts - **Isolated environments** - Each agent has its own clean working directory - **Faster iteration** - Multiple AI assistants can tackle different aspects of a task concurrently Sharing this configuration allows other team members to leverage the same workflow for Next.js development. ## How? The configuration includes: 1. **Setup script** that runs when creating a new workspace: - Enables corepack for pnpm - Validates Node.js version (18+) - Installs dependencies with `--prefer-offline` - Runs `pnpm build` 2. **Run script** that starts watch mode (`pnpm --filter=next dev`) for fast iteration 3. **Environment variables** to disable telemetry during development 4. **Gitignore entry** (`.conductor/*/`) to prevent accidentally committing worktree contents
### What? Adds a configurable `experimental.maxPostponedStateSize` limit for PPR postponed state body parsing to prevent OOM/DoS attacks. ### Why? The postponed state body was read entirely without size limits, creating a potential denial-of-service vector through unbounded memory allocation. ### How? Enforces a 10 MB default limit (configurable via next.config.js) with byte counting during body parsing. Returns HTTP 413 when exceeded with a helpful error message directing users to increase the limit if needed. <!-- Closes NEXT- --> <!-- Fixes # -->
Update to swc_core v50.2.3 to address a parse issue with mdx files that should be fixed by swc-project/swc#11372: - Fixes vercel#87713 - Internal discussion: https://vercel.slack.com/archives/C04KC8A53T7/p1766716756273609?thread_ts=1766712717.419489&cid=C04KC8A53T7 I'm intentionally not updating to the latest SWC here to reduce risk, as I'd like to cherry-pick this into the Next 16.1 branch. Changelog: https://github.com/swc-project/swc/blob/f9b4da2bd85d160b3ee4b3296ed520388675b90e/CHANGELOG-CORE.md#swc_corev5023---2025-12-15
## What? Improves the error shown when `generateMetadata` or `metadata` is exported from a Client Component. Also updated the documentation to further explain why it can only be used in a server component and the steps to follow to resolve the error.
…88157) ## 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 Add per-metric significance thresholds that account for variance. **Time metrics** (high variance from CI): - Dev boot: <100ms AND <15%, OR <3% - Build times: <500ms AND <5%, OR <2% **Size metrics** (deterministic): - node_modules: <10KB AND <1%, OR <0.01% - Bundle sizes: <2KB AND <1%, OR <0.1% ## Problem Current thresholds flag insignificant changes as regressions: - 3.45 KB change on 457 MB node_modules (0.0008%) was flagged as a regression ## Solution Use per-metric thresholds with OR logic for very small percentage changes: - Time metrics need more generous thresholds due to CI variance - Size metrics can be tighter since they're deterministic ## Test plan - Verify that 3.45 KB on 457 MB (0%) is now marked as insignificant - Verify that real regressions (>0.1% for sizes, >3% for times) are still flagged --- Stack: - vercel#88157 - **→ This PR**
…cel#87946) ## What Adds a `--experimental-cpu-prof` flag to `next dev`, `next build`, and `next start` commands to capture V8 CPU profiles for debugging performance bottlenecks. ## Why When investigating slow builds, slow dev server startups, or production server performance issues, having access to CPU profiles is invaluable. This provides a first-party way to capture these profiles without needing to manually set up the V8 inspector. ## How - Adds `--experimental-cpu-prof` flag to CLI commands - Uses V8's built-in CPU profiler via Node.js inspector module - Profiles are saved to `.next/cpu-profiles/` with descriptive filenames - Profiles are saved on process exit (Ctrl+C, SIGTERM, or normal exit) ### Profile files generated **`next dev`:** - `dev-main-*` - Parent process (dev server orchestration) - `dev-server-*` - Child server process (request handling and rendering) **`next build` (Turbopack):** - `build-main-*` - Main build orchestration process - `build-turbopack-*` - Turbopack compilation worker **`next build` (Webpack):** - `build-main-*` - Main build orchestration process - `build-webpack-client-*` - Client bundle compilation worker - `build-webpack-server-*` - Server bundle compilation worker - `build-webpack-edge-server-*` - Edge runtime compilation worker **`next start`:** - `start-main-*` - Production server process ## Changes addressing PR review comments - Removed signal handlers from `cpu-profile.ts` to prevent conflicts with CLI cleanup logic (telemetry, traces, etc.) - Added synchronous exit handler for non-signal process exits (errors, `process.exit()` calls) - CLI commands now explicitly call `saveCpuProfile()` as part of their cleanup before exiting - Replaced raw ANSI escape codes with `picocolors` library - Added comprehensive documentation about profile file naming for each command - Added build profiling test that verifies correct profile generation for both Turbopack and Webpack modes --------- Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
…ercel#88182) ## What? Adds `experimental.devCacheControlNoCache` to test `no-cache` vs `no-store` for development. Note: This is for testing only right now. If it's an improvement we'll change the default.
…vercel#87106) ### What? Making a batch read from database can be more efficient: * Order keys by hash for better cache locallity (in AMQF, key blocks, value blocks) * Use binary search to filter keys by min/max hash of the SST files * Only need to check family once instead of per key Prefetch tasks with batch reads. Add helper for "for each task" which can use batch read. add tracing for database reads
…74818) ## What? In order for Next.js to know where the root of the project (i.e. monorepo) is we have a heuristic for searching for the root by looking upwards from the application's directory trying to find the package manager lockfiles. This works really well and in practice you rarely have to provide the root directory. In some cases, e.g. when you're creating a monorepo based on an existing repository you might forget to delete the previous repository lockfile. E.g. in vercel#74731 that was the cause for the issue. While having that lockfile in the repo doesn't do anything it does affect the project root heuristic because that unused lockfile is matched on the filesystem and is higher up than the actual root (in the application directory). While looking at the reproduction in vercel#74731 I realized we can consider `pnpm-workspace.yaml` first before matching the lockfiles. Still need to verify if we need a separate findup call for that or if it will recursively look up per item first. Fixes vercel#74731 <!-- 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? When expanding the followers of a list of followers, we often have duplicates. This adds deduplication and a count for the followers of followers and makes these updates way more efficient.
The cache handlers are generally responsible for adding debug logs to their methods, see `packages/next/src/server/lib/cache-handlers/default.ts` for reference. However, the `'use cache'` wrapper in `packages/next/src/server/use-cache/use-cache-wrapper.ts` also adds a few debug logs of its own that pertain to logic that is specific to the wrapper itself, e.g. when discarding cache entries because of tag revalidation. With this PR, we're now also logging cache hits and misses in the Resume Data Cache, as well as when entries are omitted from the static or runtime shell due to their revalidate, expire or stale values. Docs: https://nextjs.org/docs/app/api-reference/directives/use-cache#verbose-logging
## Enhance test documentation with best practices and non-interactive test generation ### What? Expanded the AGENTS.md documentation with detailed guidance on writing tests, including: - Added non-interactive test generation instructions for AI agents - Documented best practices for writing tests with code examples - Provided clear guidance on using `retry()` instead of deprecated `check()` or `setTimeout` - Added recommendations for using fixture directories over inline file definitions
### What? Add a list of changed defined env vars to the trace file
When [verbose cache logging](https://nextjs.org/docs/app/guides/incremental-static-regeneration#verifying-correct-production-behavior) is enabled, we were always adding a debug log as follows after rendering a page (during prerendering or at request time): ``` pending revalidates promise finished for: { auth: null, host: null, hostname: null, pathname: '/', port: null, protocol: null, query: undefined, search: '', hash: '', href: '/', slashes: null } ``` However, if there were no pending revalidates to process, this log is misleading as it suggests that there were pending revalidates that have now been processed, while in reality there were none. So with this PR, we now only log this message if there are actually any pending revalidates, i.e. some tags were revalidated, a `fetch` cache entry was revalidated, an `unstable_cache` entry was revalidated, or a `'use cache'` entry was saved to a cache handler. In addition, the log is now shortened to only log the URL string instead of the full URL object for better readability, e.g.: ``` pending revalidates promise finished for: / ```
Release notes: https://github.com/lovell/sharp/releases/tag/v0.34.5 - Upgrade to libvips v8.17.3 for upstream bug fixes. - Add experimental support for prebuilt Linux RISC-V 64-bit binaries. - Support building from source with npm v12+ - Add support for BigTIFF output. - Improve error messaging when only warnings issued. - Simplify ICC processing when retaining input profiles.
Refactoring/cleanup, no behavioral changes
…#88229) The transform output for 'use cache' uses `Object.defineProperty` and `Array.prototype.slice`. In theory, it's possible for a module to shadow those names and break it: ```ts // i want to suffer! const Array = {} const Object = {} async function cached() { "use cache" ... } ``` We should defensively make sure that our transform's output refers to the actual Object/Array builtins, not whatever's in scope for that name. We can do this by using an unresolved syntax context for the identifiers. This is what we do for `require()` elsewhere: https://github.com/vercel/next.js/blob/6805af48baf1128e6b2a9e8f1752ee5982f02c60/crates/next-custom-transforms/src/transforms/track_dynamic_imports.rs#L119-L122 Using `quote_ident!(unresolved_ctxt, "Array")` will cause SWC to rename any local redefinitions of `Array` to something that doesn't clash (which can be seen in the added snapshots).
Support multi denied_paths in `DiskFileSystem`, it's useful to reduce redundant task invalidation.
React already disallows javascript URLs. This change extends this prohibition to Next.js specific APIs that don't serialize to an href on an anchor tag. There are workarounds if need be but this is considered a bugfix because these URLs are non-routable and the affected APIs were never intended to work with these URLs. This replaces prior efforts here: vercel#64779 which attempted to make this capability optional. We decided it was just not supportable and since workarounds exist the burden of upgrading through this bugfix is acceptable. --------- Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
Somewhat surprisingly, no breaking API changes swc-project/swc@v1.15.5...v1.15.8 tracks the changes
This was caught by our React 18 tests which only run on `canary`. There was a console error about breaking `javascript:` urls in an upcoming React release but it didn't actually block them.
…el#88242) We may have many `Invalidator`s, and we're often looping over collections of them. Instead of storing a weak reference to `TurboTasksApi` and tokio's `Handle` inside of `Invalidator`, it's better for the callsite to track this. `Weak<dyn TurboTasksApi>` and `Handle` are both 16-byte fat pointers, and there's some alignment overhead, so **this reduces the size of Invalidator from 40 bytes to 4 bytes** (according to RA), and reduces the number of refcount increment/decrements we have to do when using invalidators. These changes were LLM-generated, with careful manual review and cleanup.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
18 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🔄 Upstream Sync
This PR syncs the latest changes from the upstream repository.
Changes: 60 new commit(s) from upstream
Recent Upstream Commits:
This PR was automatically created by the multi-repo orchestrator.
Repository: next.js
Timestamp: 2026-01-08T06:47:25.942841