[pull] canary from vercel:canary#1034
Merged
Merged
Conversation
### What?
Adds a new `chunkLoadingGlobal` option to the `turbopack` config in
`next.config.js` that overrides the global variable name used for
Turbopack chunk loading (defaults to `TURBOPACK`).
```js
// next.config.js
module.exports = {
turbopack: {
chunkLoadingGlobal: 'myApp',
},
}
```
### Why?
When multiple Turbopack-built apps run on the same page (e.g. horizontal
micro-frontends), they each try to use `globalThis.TURBOPACK` which
causes conflicts. This option allows each app to use its own isolated
global, mirroring webpack's `output.chunkLoadingGlobal`.
The `chunk_loading_global` method was already wired into Turbopack in
#88790 — this PR exposes it via Next.js config.
A reason is
[vercel/remote-components#239](vercel/remote-components#239),
which uses this option to eliminate four brittle `globalThis.TURBOPACK`
regex rename transforms in the remote-components runtime. Those
transforms target Turbopack's internal variable naming and have already
required updates as Turbopack's output format evolved. With
`chunkLoadingGlobal` set at build time, Turbopack handles the renaming
natively and those transforms become unnecessary.
### How?
- `config-shared.ts` / `config-schema.ts` — adds `chunkLoadingGlobal?:
string` to `TurbopackOptions` with Zod validation
- `next_config.rs` — adds the field to `TurbopackConfig` and a
`turbopack_chunk_loading_global()` accessor
- `next_client/context.rs` — threads it through
`ClientChunkingContextOptions` and calls
`builder.chunk_loading_global()` when set
- `project.rs` — wires the config into the client chunking context
options
Only applies to the browser/client chunking context — server and edge
runtimes don't have this concept.
### Test plan
- `pnpm test-start-turbo
test/production/app-dir/turbopack-chunk-loading-global/turbopack-chunk-loading-global.test.ts`
<!-- NEXT_JS_LLM_PR -->
---------
Co-authored-by: Niklas Mischkulnig <4586894+mischnic@users.noreply.github.com>
…92897) ### What? When an in-progress task is invalidated during execution, it transitions to a "stale" state. Previously, on completion it was directly re-executed in the same worker slot — inheriting the original schedule priority rather than the priority from the invalidation that made it stale. ### Why? A stale task that was invalidated at low priority was being re-executed at whatever high priority the original schedule had. This caused high-priority work to be unfairly blocked or deprioritized in the scheduler. ### How? **`backend.rs` trait:** `task_execution_completed` return type changed from `bool` (reschedule yes/no) to `Option<TaskPriority>` — `None` means done, `Some(priority)` means the task was stale and must be re-executed at this priority. **`backend/mod.rs`:** The three helper functions (`_prepare`, `_connect`, `_finish`) and the main `task_execution_completed` all propagate the invalidation priority on stale returns. In each stale path, the priority is read from `task.is_dirty().unwrap_or(TaskPriority::leaf())` before the task state is mutated. **`manager.rs`:** The executor no longer loops to directly re-execute stale tasks. Instead, if `task_execution_completed` returns `Some(stale_priority)`, the task is unconditionally re-scheduled through the priority runner at that priority, so all tasks execute in the correct priority order. <!-- NEXT_JS_LLM_PR -->
### What?
The primary error description renders its message through
`HotlinkedText`, so `Learn more: https://...` URLs become real links.
The nested overlay surfaces — `Caused by` (`error-cause.tsx`) and
aggregate-error rows (`error-aggregate-errors.tsx`) — still rendered the
trimmed message as plain `<p>` text, leaving those URLs unclickable.
### How?
Wrap `{trimmedMessage}` in `<HotlinkedText>` on both surfaces. Default
browser link color (blue) is left intact so the URLs stand out against
the red message text.
Before:
<img width="1332" height="1234" alt="CleanShot 2026-05-08 at 00 15
42@2x"
src="https://github.com/user-attachments/assets/88cf519d-3b7e-47a8-a963-429d480b3229"
/>
After:
<img width="1100" height="1098" alt="CleanShot 2026-05-08 at 00 15
14@2x"
src="https://github.com/user-attachments/assets/91bcb1fd-a446-4969-b3f1-77df9659613d"
/>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
When optimistic routing is enabled, the client uses responses it receives from the server (during a navigation or a prefetch) to resolve the routes of structurally similar URLs. However, if the server rewrites a URL to a different path than the one requested by the client, then we disable optimistic routing for that pattern. We detect a rewrite by comparing the route tree returned from the server to the requested URL. If the route tree does not match, according to the Next.js routing algorithm, then the route must have been rewritten; we do not write this pattern into the client's route table. The basic mechanism for this was already implemented, but there were some cases we weren't handling correctly: - A static or non-optional dynamic segment is reached with no URL part to consume. - A page leaf is reached with URL parts still pending. - A dynamic segment whose URL part matches one of its known static siblings (which would have taken precedence under normal routing). These cases have been fixed. Regression tests live in `optimistic-routing-rewrite-detection-regression/` and `optimistic-routing-parallel-slot-catchall-regression/`. --- Replaces #93578 (re-opened from an `origin` branch to satisfy CI requirements).
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )