test: v16.2.0 -> v16.2.6 (PR review retry after install fix)#7
Open
msrkp wants to merge 76 commits intopr-review/base-v16-2-0-r2from
Open
test: v16.2.0 -> v16.2.6 (PR review retry after install fix)#7msrkp wants to merge 76 commits intopr-review/base-v16-2-0-r2from
msrkp wants to merge 76 commits intopr-review/base-v16-2-0-r2from
Conversation
…cel#91666) ### What? Fixed Turbopack incorrectly trying to resolve inline JavaScript code as module references when `new Worker()` is called with `{ eval: true }` option. Now we skip creating a reference when `eval:true`, and report warnings if we cannot tell what the value is ### Why? Libraries like jsPDF create Worker threads by passing inline JavaScript code as the first argument along with `{ eval: true }` as the second argument. Turbopack was incorrectly treating this inline code as a file path and attempting to resolve it as a module reference, causing build failures. ### How? Added logic to detect when the `eval: true` option is passed to the Worker constructor. When this option is present, Turbopack now skips creating a worker reference since the first argument contains executable code rather than a file path. Added comprehensive test coverage using jsPDF to verify the fix works correctly. Fixes vercel#91642
A regression from vercel#88487 1. Make metadata import lazy with `() => require()`, just like for the layout segments 2. Properly await the return value to better handle TLA modules This align with Webpack which does this: <img width="1535" height="509" alt="Bildschirmfoto 2026-03-20 um 11 58 00" src="https://github.com/user-attachments/assets/f2864c86-ccce-4884-8417-c8ae06c05f78" /> Closes PACK-6927 Closes vercel#91700 Closes vercel#91676
…ity transition (vercel#91701) ## Summary - Add `'turbopack-transition': 'next-server-utility'` to all server-side imports in the `app-page.ts` template so they are properly placed in the server utility layer, rather than relying on `SharedMerged` chunk groups to handle them - Remove the now-unnecessary `next-server-utility` transition from `fillMetadataSegment` import in `app_page_loader_tree.rs` - Add `SharedMultiple` chunk group variant to support multiple shared entries without a merge tag - This avoid passing the `parent` into `SharedMerged`, which did break the layout segment optimization. - Refactor `app_module_graphs` to combine `client_shared_entries` + `has_layout_segments` into a single `Option` parameter, simplifying the API and removing the dead code path for non-page endpoints ## Test plan - [ ] Verify dev and production builds work with app pages that have layout segments - [ ] Verify route handlers still build correctly (no client runtime entries passed) - [ ] Run existing app-dir e2e tests
Remove the `MADV_UNMERGEABLE` (Unmergeable) mmap advice from `turbo-persistence`'s `advise_mmap_for_persistence` helper in `mmap_helper.rs`. The WSL (Windows Subsystem for Linux) kernel does not support `MADV_UNMERGEABLE` and returns an error when it is applied, causing turbo-persistence to fail on WSL. See: https://x.com/von_cronen/status/2034944304712392891 Additionally, `MADV_UNMERGEABLE` is already the **default** state for memory pages — KSM (Kernel Same-page Merging) is opt-in via `MADV_MERGEABLE`. Explicitly setting `MADV_UNMERGEABLE` on pages that were never marked mergeable is a no-op on standard kernels, so the call provides no benefit while breaking WSL users. The `MADV_DONTFORK` advice is retained, as it has a clear correctness benefit (prevents mmap regions from being inherited by child processes on `fork()`). Removed the `mmap.advise(memmap2::Advice::Unmergeable)` call and its associated doc comment from `turbopack/crates/turbo-persistence/src/mmap_helper.rs`. Co-authored-by: Tobias Koppers <sokra@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
…91711) The `staticPathKey` condition added in vercel#91231 inadvertently applies to server action requests on dynamic SSG routes when `cacheComponents` is enabled. Server action fetch requests from the client do not send the `RSC` header (`rsc: 1`). They only send `Accept: text/x-component` and the `Next-Action` header. This means `isRSCRequest` and `isDynamicRSCRequest` are both `false` for action requests. The new `staticPathKey` condition (`isSSG && pageIsDynamic && prerenderInfo?.fallbackRouteParams`) evaluates to `true` for dynamic PPR routes, setting `staticPathKey` even though `ssgCacheKey` is `null` for actions. With `staticPathKey` set, the request enters the fallback rendering block, which serves the cached fallback HTML shell with the action result appended to it, instead of responding with just the RSC action result. The fix excludes server action requests from the `staticPathKey` computation by adding `!isPossibleServerAction` to the condition, restoring the pre-vercel#91231 behavior where `staticPathKey` was always `null` for server actions in production. fixes vercel#91662 closes vercel#91677 closes vercel#91669
Otherwise you get a `Dependency tracking is disabled` / infinite loop when trying to use both turbopack.rules.loader and turbopackLoader at the same time
## Summary This fixes adapter `onBuildComplete` outputs for dynamic metadata routes. ## Bug `handleBuildComplete` skipped metadata routes too aggressively via `isStaticMetadataFile(...)`, so dynamic metadata routes (for example `robots.txt` / `sitemap.xml` using `connection()`) were omitted from `outputs.appRoutes`. ## Fix Only skip metadata routes when they are actually prerendered/static (present in prerender manifests). Dynamic metadata routes are now included in adapter `outputs.appRoutes` as expected. ## Tests Added e2e coverage in `test/e2e/app-dir/adapter-dynamic-metadata`: - verifies dynamic `robots.txt`, `sitemap.xml`, and `favicon.ico` functionality - verifies adapter output classification for non-deploy runs - skips output-shape verification in deploy mode - skips the suite in dev mode
…uide (vercel#91698) ## What? Fixes a broken link in the Preserving UI State guide: https://nextjs.org/docs/app/guides/preserving-ui-state#examples The "Activity Patterns demo" link currently points to a non-working URL. ## Why? The demo link returns a 404 / invalid page, which makes the example section confusing for readers. ## Changes - Updated the Activity Patterns demo link to the correct URL. ## Notes No functional changes, docs only. @icyJoseph @delbaoliveira
Fixes based on feedback post release Fixes: vercel#91715
Backporting 1. `0e598d2131` — docs: use ErrorInfo type consistently in catchError docs (vercel#91744) 2. `70760c201b` — docs: add catchError benefits over userspace error boundaries (vercel#91745) 3. `1f920cd057` — docs: platform portability and infrastructure documentation (vercel#91237) 4. `5d2b57b051` — docs: add verified adapters section (vercel#91849) --------- Co-authored-by: Jiwon Choi <devjiwonchoi@gmail.com> Co-authored-by: Jimmy Lai <laijimmy0@gmail.com> Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
…vercel#92129) ## Summary - move adapter implementation docs from `app/api-reference/config/next-config-js/adapters` to `app/api-reference/adapters` - keep `adapterPath` as an entry page that points to the new adapters section - add matching Pages Router pointer docs under `pages/api-reference/adapters` - update existing docs links that referenced old `adapterPath#...` anchors to the new adapters routes <!-- 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 # -->
vercel#91840) When AI agents run `create-next-app` with explicit flags like `--typescript --tailwind --eslint --app --src-dir`, the CLI still enters interactive mode and prompts for any unspecified options: ``` ➜ npx create-next-app my-app --typescript --tailwind --eslint --app --src-dir --use-pnpm ✔ Would you like to use React Compiler? … No / Yes ✔ Would you like to customize the import alias (`@/*` by default)? … No / Yes ? Would you like to include AGENTS.md to guide coding agents to write up-to-date Next.js code? › No / Yes ``` Agents can sometimes answer these interactive prompts correctly, but often they can't. When they fail to navigate the prompts, they fall back to scaffolding the project themselves from scratch — generating files based on stale training data. This means they might initialize an app using deprecated patterns or pin to an older version of Next.js (e.g. 15) instead of the latest. Using `create-next-app` non-interactively is the best way to ensure agents always produce up-to-date scaffolding. Previously, `hasProvidedOptions` only skipped the initial "use recommended defaults?" meta-prompt but still showed individual prompts for each missing option. Now when any config flags are provided, all remaining options use the recommended defaults without prompting. The resolved defaults are printed to stdout so the caller knows exactly what was assumed and which flags to pass to override: ``` Using defaults for unprovided options: --eslint ESLint (use --biome for Biome, --no-eslint for None) --no-react-compiler No React Compiler (use --react-compiler for React Compiler) --agents-md AGENTS.md (use --no-agents-md for No AGENTS.md) --import-alias "@/*" To customize, re-run with explicit flags. ``` The `displayConfig` array is extended with a `flags` field so this output is auto-generated from the same source of truth used for the interactive prompts. Existing behavior for `--yes`, CI mode, and fully interactive mode (no flags) is unchanged.
### What? Adds `experimental.serverFastRefresh` to `next.config.js` so users (and Next.js plugins) can opt out of server-side Fast Refresh without needing to pass a CLI flag. Also adds a `--server-fast-refresh` positive CLI flag (hidden) alongside the existing `--no-server-fast-refresh`, and emits a warning when the CLI flag and config value conflict. This is a necessary implementation detail for `commander` to detect when no option is provided. ### Why? Certain Next.js plugins have encountered issues with server Fast Refresh and need a way to disable it programmatically via config rather than requiring users to modify their start scripts. The CLI-only opt-out (`--no-server-fast-refresh`) was insufficient for this use case. ### How? - **`config-shared.ts` / `config-schema.ts`**: Added `experimental.serverFastRefresh?: boolean` to the `ExperimentalConfig` type and Zod schema. - **`router-server.ts`**: Resolves the effective `serverFastRefresh` value at startup by combining the CLI flag (`opts.serverFastRefresh`) and `nextConfig.experimental.serverFastRefresh`, with CLI taking precedence. Emits a `Log.warn` when both are set to conflicting values. Defaults to `true` when neither is specified. - **`bin/next.ts`**: Fixed the Commander option definition for `--no-server-fast-refresh`. Commander's `--no-X` pattern implicitly creates a positive `--server-fast-refresh` option defaulting to `true`, which meant `opts.serverFastRefresh` was never `undefined` and the config value could never take effect. Fixed by explicitly registering a hidden `--server-fast-refresh` option with `.default(undefined)`. - **Tests**: Added two new test suites in `test/development/app-dir/server-hmr/server-hmr.test.ts`: - `server-hmr config opt-out` — verifies that setting `experimental.serverFastRefresh: false` in config causes unmodified dependencies to be re-evaluated (i.e., server HMR is disabled). - `server-hmr CLI/config conflict warning` — verifies that passing `--no-server-fast-refresh` when config has `serverFastRefresh: true` logs the conflict warning. ### Test Plan - [x] Added e2e development tests (`test/development/app-dir/server-hmr/server-hmr.test.ts`) — all 8 tests pass --------- Co-authored-by: Will Binns-Smith <wbinnssmith@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
App router handlers are already built with the Turbopack runtime, so they can use server HMR. **We also already get subscription events for their chunks.** However, unlike app pages which use `__next_app__.require()` for dynamic devModuleCache lookup, route handlers capture userland exports statically in AppRouteRouteModule at construction time. This change makes routes behave a lot like pages, dynamically loading the user's code when requests are made. This way, we can freely invalidate and reload it when changes are made without evicting the entire require cache. Only `next dev` uses this lazy evaluation, as `next start` continues to eagerly import route handlers. This change removes the `isAppPage` restriction from `usesServerHmr`, extending server HMR coverage to all App Router entries (pages and route handlers) built with the Node.js runtime. For route handlers, we also clear the entry chunk from Node.js `require.cache` on each rebuild so the next `requirePage()` call re-executes the entry and obtains fresh module exports from `devModuleCache` (which HMR updates in-place). Test Plan: Added an additional e2e test, `with-dep`
### What? Metadata routes (`manifest.ts`, `robots.ts`, `sitemap.ts`, `icon.tsx`, `apple-icon.tsx`, etc.) were not being hot-reloaded in Turbopack dev mode — changes to those files would not be reflected on subsequent requests until a full server restart. ### Why? PR vercel#91466 extended `usesServerHmr = true` in `clearRequireCache()` (in `hot-reloader-turbopack.ts`) from `app-page` entries only to **all** `app`-type entries (pages + route handlers). The motivation was correct: regular route handlers like `app/api/hello/route.ts` use Turbopack's in-place module update model and benefit from server HMR. However, metadata routes (`/manifest.webmanifest/route`, `/robots.txt/route`, etc.) are also `app`-type entries but they are **not** suitable for in-place server HMR. When `usesServerHmr = true` for a metadata route, `clearRequireCache()` skips two critical invalidation steps: 1. Deleting the compiled chunk from `require.cache` 2. Calling `__next__clear_chunk_cache__()` Without those steps, the old module stays in-memory and all subsequent requests to `/manifest.webmanifest` (etc.) return the stale content. ### How? Added an `!isMetadataRoute(entryPage)` guard to the `usesServerHmr` expression in `clearRequireCache()`. This restores full cache invalidation for metadata routes on every rebuild while leaving regular route handler server HMR (added in vercel#91466) intact. ```ts // Before const usesServerHmr = serverFastRefresh && entryType === 'app' && writtenEndpoint.type !== 'edge' // After const usesServerHmr = serverFastRefresh && entryType === 'app' && writtenEndpoint.type !== 'edge' && !isMetadataRoute(entryPage) // ← metadata routes always clear the cache ``` `isMetadataRoute('/manifest.webmanifest/route')` → `true` (excluded from server HMR) `isMetadataRoute('/api/hello/route')` → `false` (keeps server HMR, no regression) Also added a regression test: `metadata route hmr > reflects manifest.ts changes on fetch/refresh` in the `server-hmr` test suite, with a `manifest.ts` fixture that starts at `name: 'Version 0'`. The test patches the file and asserts the updated JSON is returned on the next fetch. Fixes vercel#91981 --------- Co-authored-by: Will Binns-Smith <wbinnssmith@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
## Summary - Backport of vercel#92123 to `next-16-2` release branch - Cherry-picked the CSS HMR Safari fix and regenerated turbopack-tests snapshot goldens for the release branch ## Test plan - [x] `UPDATE=1 cargo nextest r -p turbopack-tests` — all 297 tests pass - [x] `pnpm build-all` — clean build, no issues with `generated-native.d.ts`
Fixes vercel#91708 set the legacy_x86_64_support feature on qfilter to support older intel cpus
Publishing: 1. `6a2045936f` - docs: add middleware bypass note to CDN caching guide (vercel#92132) 2. `495d50f187` - docs: document revalidateTag's required second argument in upgrade guide (vercel#92134) 3. `faa4b99296` - docs: local images referenced by remote source (vercel#92178) 4. `0167a02695` - Docs/adapters review (vercel#92223) 5. `2622a53942` - docs: vt demo guide (vercel#92249) --------- Co-authored-by: JJ Kasper <jj@jjsweb.site> Co-authored-by: Aurora Scharff <66901228+aurorascharff@users.noreply.github.com>
…handling (vercel#92254) Bug fixes and a refactoring in `turbo-tasks-backend` targeting stability issues that surface when filesystem caching is enabled: 1. **Preserve `cell_type_max_index` on task error** — when a task fails partway through execution, `cell_counters` only reflects the partially-executed state. Previously, `cell_type_max_index` was updated from these incomplete counters, which removed entries for cell types not yet encountered. This caused `"Cell no longer exists"` hard errors for tasks that still held dependencies on those cells. The fix skips the `cell_type_max_index` update on error, keeping it consistent with the preserved cell data (which already wasn't cleared on error). This bug manifested specifically with `serialization = "hash"` cell types (e.g. `FileContent`), where cell data is transient and readers fall back to `cell_type_max_index` to decide whether to schedule recomputation. 2. **Fix shutdown hang and cache poisoning for cancelled tasks** — three related fixes for tasks cancelled during shutdown: - `task_execution_canceled` now drains and notifies all `InProgressCellState` events, preventing `stop_and_wait` from hanging on foreground jobs waiting on cells that will never be filled. - `try_read_task_cell` bails early (before calling `listen_to_cell`) when a task is in `Canceled` state, avoiding pointless listener registrations that would never resolve. - Cancelled tasks are marked as session-dependent dirty, preventing cache poisoning where `"was canceled"` errors get persisted as task output and break subsequent builds. The session-dependent dirty flag causes the task to re-execute in the next session, invalidating stale dependents. 3. **Extract `update_dirty_state` helper on `TaskGuard`** — the "read old dirty state → apply new state → propagate via `ComputeDirtyAndCleanUpdate`" pattern was duplicated between `task_execution_canceled` and `task_execution_completed_finish`. The new `update_dirty_state` default method on `TaskGuard` handles both transitions (to `SessionDependent` or to `None`) and returns the aggregation job + `ComputeDirtyAndCleanUpdateResult` for callers that need post-processing (e.g. firing the `all_clean_event`). These bugs caused observable failures when using Turbopack with filesystem caching (`--cache` / persistent cache): - `"Cell no longer exists"` panics/errors on incremental rebuilds after a task error. - Hangs on `stop_and_wait` during dev server shutdown. - Stale `"was canceled"` errors persisted in the cache breaking subsequent builds until the cache is cleared. Changes are in `turbopack/crates/turbo-tasks-backend/src/backend/`: **`mod.rs`:** - Guard the `cell_type_max_index` update block inside `if result.is_ok()` to skip it on error, with a cross-reference comment to `task_execution_completed_cleanup` (which similarly skips cell data removal on error — the two must stay in sync). - Move the `is_cancelled` bail in `try_read_task_cell` before the `listen_to_cell` call to avoid inserting phantom `InProgressCellState` events that would never be notified. - In `task_execution_canceled`: switch to `TaskDataCategory::All` (needed for dirty state metadata access), notify all pending in-progress cell events, and mark the task as `SessionDependent` dirty via the new helper. - In `task_execution_completed_finish`: replace ~77 lines of inline dirty state logic with a call to `task.update_dirty_state(new_dirtyness)`, preserving the `all_clean_event` post-processing and the `dirty_changed` variable under `#[cfg(feature = "verify_determinism")]`. **`operation/mod.rs`:** - Add `update_dirty_state` default method on `TaskGuard` trait (~60 lines), co-located with the existing `dirty_state()` reader. Takes `Option<Dirtyness>`, applies the transition, builds `ComputeDirtyAndCleanUpdate`, and returns `(Option<AggregationUpdateJob>, ComputeDirtyAndCleanUpdateResult)`. - Add `ComputeDirtyAndCleanUpdateResult` to the public re-exports. --------- Co-authored-by: Tobias Koppers <sokra@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
vercel#92459) ### What? Fix a race condition in the Pages Router SSR path where styled-jsx styles were dropped from the rendered HTML. ### Why? `styledJsxInsertedHTML()` reads and flushes the styled-jsx style registry. Previously it was called concurrently with the page render via `Promise.all`: ```js const [rawStyledJsxInsertedHTML, content] = await Promise.all([ renderToString(styledJsxInsertedHTML()), (async () => { /* render the page */ })(), ]) ``` Because both ran at the same time, `styledJsxInsertedHTML()` could (and in practice did) execute and flush the registry **before** the page render had finished populating it. The result was that dynamic styled-jsx styles — those with interpolated expressions that compute their class names at runtime via DJB2 hashing — were silently dropped from the SSR output, causing a flash of unstyled content on first load. This is particularly visible in production deployments where all components use dynamic styled-jsx (numeric `jsx-*` class names), since those styles only exist in the registry after rendering completes. ### How? Serialize the two operations: render the page first, then call `styledJsxInsertedHTML()`. Since the registry is fully populated by the time it is read, all styles are captured correctly. A new e2e test (`test/e2e/styled-jsx-dynamic`) exercises this scenario with multiple nested components that all use dynamic styled-jsx with interpolated props, covering the exact FOUC pattern seen in production. <!-- NEXT_JS_LLM_PR --> Co-authored-by: Tobias Koppers <sokra@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
…emit (vercel#92292) Adds deduplication and conflict detection to the asset emission stage in `crates/next-core/src/emit.rs`, and a new `IssueStage::Emit` variant in `turbopack-core`. Before emitting, assets are grouped by their output path. If multiple assets map to the same path: - If their content is identical, one is silently chosen (deduplication). - If their content differs, both versions are written to `<node_root>/<content_hash>.<ext>` and an `EmitConflictIssue` is raised for each conflict. All assets are still emitted — conflicts do not abort the build. Previously, duplicate output assets for the same path were emitted unconditionally — whichever write happened last silently won. This masked build graph bugs where two different modules produced conflicting output files. Reporting conflicts as issues (rather than silently overwriting) makes them visible and easy to diagnose without breaking the build. - Collect all assets with their resolved paths via `try_flat_join`. - Bucket them into two `FxIndexMap<FileSystemPath, Vec<ResolvedVc<Box<dyn OutputAsset>>>>` — one for node-root assets and one for client assets. - For each bucket entry, call `check_duplicates`: compare every asset against the first using `assets_diff`. If content differs, emit an `EmitConflictIssue` as a turbo-tasks collectible — but still return the first asset so emission continues. - `assets_diff` is a `#[turbo_tasks::function]` that takes only `(asset1, asset2, extension, node_root)` — the `asset_path` stays out of the task key to avoid unnecessary task cardinality. When file content differs, it hashes each version with xxh3, writes them to `<node_root>/<hash>.<ext>`, and returns the paths in the detail message so the user can diff them. - `EmitConflictIssue` implements the `Issue` trait with `IssueStage::Emit` (new variant added to `turbopack-core`), `IssueSeverity::Error`, a descriptive title, and a detail message explaining the type of conflict. - Node-root and client assets are emitted in parallel via `futures::join!` (not `try_join!`) to ensure deterministic error reporting — both branches always run to completion so errors are reported in a consistent order. --------- Co-authored-by: Tobias Koppers <sokra@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
…ercel#92273) ### What? Fix server HMR becoming unresponsive after a metadata route is loaded in the same Node.js process as an app page. ### Why? Turbopack loads separate runtime chunks for app pages and metadata routes (`robots.ts`, `sitemap.ts`, `manifest.ts`, `icon.tsx`, etc.) in the same Node.js process. Each runtime chunk embeds `dev-nodejs.ts` and produces a distinct `__turbopack_server_hmr_apply__` closure bound to its own `moduleFactories` and `devModuleCache`. Previously each runtime simply overwrote `globalThis.__turbopack_server_hmr_apply__`, so the last chunk to load silently won. Navigating to `/robots.txt` before an HMR update caused the metadata route runtime to overwrite the page runtime's handler. Subsequent HMR updates were dispatched only to the metadata route runtime, which has no knowledge of the page module — the page appeared frozen and stopped reflecting file changes. ### How? Replace the bare assignment with a multicast registry: 1. Each runtime appends its own `__turbopack_server_hmr_apply__` handler to `globalThis.__turbopack_server_hmr_handlers__[]`. 2. The first runtime to register installs a shared dispatcher as `globalThis.__turbopack_server_hmr_apply__` that iterates all registered handlers at call time (not install time), so newly loaded runtimes are always included. 3. On full cache reset, `hot-reloader-turbopack.ts` resets `__turbopack_server_hmr_handlers__` to `[]` so stale handlers from evicted chunks don't accumulate into the next generation. Because `dev-nodejs.ts` is embedded into the Turbopack binary via `include_dir!`, this fix requires rebuilding the native binary. ### Tests `test/development/app-dir/server-hmr/server-hmr.test.ts` — extended with `metadata route hmr` tests that load a metadata route before patching a page file, verifying HMR updates still reach the page runtime after a second runtime chunk is loaded. --------- Co-authored-by: Will Binns-Smith <wbinnssmith@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
… onRequestError (vercel#92282) (vercel#92519) Backports: - vercel#92282
* Avoid consuming cyclic models multiple times * make types-and-precompiled work
…adapter (vercel#91541) In a deployed environment, `onCacheEntryV2` determines whether a postponed response is HTML-origin or RSC-origin by checking whether meta.url ends with `.rsc`. For some dynamic full-route RSC requests, Next was passing a URL with query params into onCacheEntry, for example: `/[tenant]/samples.rsc?nxtPtenant=tenant-x` Because that string does not end with .rsc, `onCacheEntryV2` misclassified the request as HTML and treated it as text/html instead of an RSC response. This PR normalizes the URL before passing it to `onCacheEntry`, so the callback receives the pathname rather than the full URL-with-query. --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>
Switch CI from self-hosted runners to GitHub-hosted runners and fix the follow-up issues that showed up once the hosted jobs were exercised. - Move Linux workflows onto `ubuntu-latest-16-core-oss`, Windows workflows onto `windows-latest-8-core-oss`, and the native mac release lane onto `macos-15-intel`. - Update the reusable build workflow to work in hosted environments by relying on `runner.os` instead of label string matching, and by removing the hardcoded `/home/runner` `fnm` path. - Make Turbo/sccache configuration explicit for hosted runners: - unify on `vtest314-next-adapter-e2e-tests` - pass `TURBO_TOKEN` via workflow env/secrets instead of assuming runner-level env - switch Turbo cache mode to `local:rw,remote:rw` so jobs still have local cache behavior when remote cache is unavailable - Update the `sccache` action defaults/docs to use the hosted-runner secret setup (`TURBO_TOKEN`) instead of the old self-hosted token wiring. - Make Datadog reporting fail open so missing `DATA_DOG_API_KEY` does not block CI. - Fix the CLI reserved-port test so it asserts Next’s own `-p 1` validation instead of failing earlier on hosted Linux due to privileged-port binding. - Replace the live `musl.cc` dependency in `native-builder.Dockerfile` with musl sysroots imported from GHCR-hosted `rust-musl-cross` images, keeping the existing `/opt/*-cross` layout used by the Linux native build scripts. - Fix the macOS native build workaround s so it applies to all *-apple-darwin targets based on the Cargo target OS rather than the host architecture, which avoids napi-build injecting the unsupported -Wl linker arg when @next/swc is linked with rust-lld on hosted mac runners. Test Plan: - This PR's CI - This [build_and_deploy](https://github.com/vercel/next.js/actions/runs/24865715983/job/72801225722) job running on every arch
## Summary - backport the fallback route params fix from vercel#91737 onto `next-16-2` - preserve intermediate shells that suspend only for unresolved fallback params during staged rendering - add the missing `resolvedRouteParamKeys` request metadata needed by this branch
Switches from a long-lived token to trusted publishing OIDC flow. This requires a bump to Node (for feature support). Otherwise just dropping unnecessary envs. (cherry picked from commit 129896c)
Moves the `environment` into `publishRelease` rather than `trigger_release` since the actual action we want to create environment rules for is the publish step. (cherry picked from commit 2b846de)
Moves all release workflows off of a GH PAT and uses an app with a short-lived token instead. Test Plan: Dry run [here](https://github.com/vercel/next.js/actions/runs/24934593874). However, this workflow is blocked until we figure out commit signing for the bot app. Some options: - The bot account generates a signing key and we use it in CI (not great, bypasses the app) - The org bypasses signature verification for the bot user (also not great, requires an exemption rule) - We need to rework the commit step so Lerna does not do the push, and instead trigger it via the app + GH API. This seems like the best option, will be added in a follow-up PR. Note: `create-release-branch` workflow is broken in its current form, as we will not be restoring administrator privileges to adjust environment settings. This will become a manual step in the future. (cherry picked from commit e69de2f)
Stacked on vercel#93245 Commit signing is required for anything that lands on `canary`. Our previous workflow of using a PAT to push a commit no longer works, since that would have been an unsigned commit. In vercel#93245 we switched to an app token for release workflow steps. This continues by: - Telling Lerna to bump packages but not commit - Creating a signed commit with the staged changes via GitHub's API - Then running the publish flow Test Plan: Dry run [here](https://github.com/vercel/next.js/actions/runs/25001287978/job/73211826479) Commit [here](vercel@3a8456a) (cherry picked from commit 012fd7d)
…dlx or npx (vercel#92546) `pnpm dlx` isn't using a lockfile. Using the self-contained binary from GitHub and validate the checksum lets us effectively pin `datadog-ci` and all of its possible transitive dependencies. This is a follow-up for https://vercel.slack.com/archives/C0APPN2LC83/p1775073127894859 (cherry picked from commit 631fae9)
Backport vercel#93453 to 16.2 How was this ever working for dev? In that case, `buildId = "development"` and so it always uses the same cache key Co-authored-by: Niklas Mischkulnig <4586894+mischnic@users.noreply.github.com>
…parsing (vercel#93506) Backports: - vercel#93491
Backports: - vercel#91912 - vercel#93365 --------- Co-authored-by: Sebastian "Sebbie" Silbermann <sebastian.silbermann@vercel.com>
…ery (vercel#93470) Backports: - vercel#92231 --------- Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com> Co-authored-by: Andrew Clark <git@andrewclark.io>
props set on a next/script with beforeInteractive are serialized as JSON into an inline script to be exectuted prior to hydration by Next.js. The props were not additionally escaped and if user input was rendered as through a script it could allow fro XSS. This has alwways been true if you pass user input into the script body or via dangerouslySetInnHTML however and it is always the developers responsibility to sanitize user input before rendering. However wherever React has some automatic escaping to act as an additional defense against common mistakes leading to vulnerabilities like XSS Next.js should mirror that becasue from the user's perspective it is not clear that React is not directly rendering the script props and content. This change adds additional escaping so that serialized properties cannot break out of the script scope and execute unexpected payloads.
* Fix i18n middleware matching for default-locale data routes * unskip node middleware on deploy
* test: add rewrite request smuggling coverage * router-server: guard upgrade proxy against absolute-url SSRF * test: relax rewrite smuggling socket timeout * router-server: preserve local websocket upgrades
we have auditing that server files aren't included in client chunks but the new htmlescape usage in next/script is causing that validation to fail. This refactors the utility into lib/shared
This header is used by proxies to perform a concatenating resume render for partial prerendering. It is never sent from the client so we can filter it out when running in a mode that does not have an intermediate proxy.
Co-authored-by: Niklas Mischkulnig <4586894+mischnic@users.noreply.github.com> Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
…deploys (vercel#93586) Co-authored-by: Matt Mastracci <matthew@mastracci.com>
## What? The Turbopack path incorrectly included a double backslash instead of one backslash in the regex matcher.
…3594) ## What? Applies vercel@d166096 for canary and handles the Turbopack-side implementation for `middleware-manifest.json` which is used for edge runtime middleware.ts --------- Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
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
19 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.
Retry scan after removing the duplicate next.js GitHub App install.
v16.2.0(c5c94dffbf084e66b172a9c6ff23d80c24973764)v16.2.6(ee6e79b1792a4d401ddf2480f40a83549fe8e722)Not intended to be merged.