Comparing changes

Backporting 1. `0e598d2131` — docs: use ErrorInfo type consistently in catchError docs (#91744) 2. `70760c201b` — docs: add catchError benefits over userspace error boundaries (#91745) 3. `1f920cd057` — docs: platform portability and infrastructure documentation (#91237) 4. `5d2b57b051` — docs: add verified adapters section (#91849) --------- Co-authored-by: Jiwon Choi <[email protected]> Co-authored-by: Jimmy Lai <[email protected]> Co-authored-by: JJ Kasper <[email protected]> Co-authored-by: Tim Neutkens <[email protected]>

## 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

…#92130) backports: #91855 backports: #91847

#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 <[email protected]> Co-authored-by: Claude <[email protected]>

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 #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 #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 #91981 --------- Co-authored-by: Will Binns-Smith <[email protected]> Co-authored-by: Claude <[email protected]>

## Summary - Backport of #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 #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 (#92132) 2. `495d50f187` - docs: document revalidateTag's required second argument in upgrade guide (#92134) 3. `faa4b99296` - docs: local images referenced by remote source (#92178) 4. `0167a02695` - Docs/adapters review (#92223) 5. `2622a53942` - docs: vt demo guide (#92249) --------- Co-authored-by: JJ Kasper <[email protected]> Co-authored-by: Aurora Scharff <[email protected]>

)

…handling (#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 <[email protected]> Co-authored-by: Claude <[email protected]>

#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.  Co-authored-by: Tobias Koppers <[email protected]> Co-authored-by: Claude <[email protected]>

…emit (#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 <[email protected]> Co-authored-by: Claude <[email protected]>

…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 <[email protected]> Co-authored-by: Claude <[email protected]>

… onRequestError (#92282) (#92519) Backports: - #92282

* Avoid consuming cyclic models multiple times * make types-and-precompiled work

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comparing changes

Open a pull request

Commits on Mar 26, 2026

Commits on Mar 31, 2026

Commits on Apr 2, 2026

Commits on Apr 7, 2026

Commits on Apr 8, 2026

This comparison is taking too long to generate.

Uh oh!