[pull] canary from vercel:canary - #1325
Merged
Merged
Conversation
On scheduled runs of the Update React workflow, `github.actor` often resolves to `github-actions[bot]`, which cannot be assigned to pull requests in `vercel/next.js`. Since the sync switched to the GitHub App token, adding a non-assignable assignee fails the request with 403 e.g. https://github.com/vercel/next.js/actions/runs/32392135342/job/96500520936#step:8:781 (user tokens silently ignored it instead), which failed the entire sync run and raced the in-flight reviewer request, leaving the created pull request without a reviewer. The script now checks assignability and skips assignment with a warning when the actor cannot be assigned, and the finalize requests (assign, request reviewers, add labels) run through `Promise.allSettled`, with any failures rethrown together as an `AggregateError` so the run still fails on real errors. Co-authored-by: Claude Code (kimi-k3[1m]) <noreply@anthropic.com>
Previously, Turbopack treated `_app` and Pages router pages as completely separate. So using code both in `_app` and `pages/foo.tsx` would lead to a lot of duplicated code to be loaded at runtime. But in reality, `_app` is always loaded for Pages, so we can thread the availability info and skip chunking modules that were already loaded by `_app`. Recreation of #97549 Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com>
## Summary When two Next.js microfrontend child applications run in development mode at the same time, their HMR clients conflict because they share the same global chunk-update listener registry. Since turbopack added support for the chunkloadingglobal configuration, I think this configuration can also consume HMR's global object simultaneously: PR: #88790 and #93488 This change scopes the listener registry to each runtime chunk-loading global so the applications can receive HMR updates independently. ## Test Update snapshot test case
#96559) Eager glob values were built with a plain CommonJS require, so the value was a module's `exports` object rather than its ESM namespace — for JSON (or any CommonJS) module that meant no CommonJS interop ran, so `modules[path].default` (the shape our own docs show) and `{ import: 'default' }` were `undefined`. A hand-written `import * as ns from './data.json'` did have `default`. Eager values now use the same namespace-import primitive a static `import * as ns from '…'` produces. <!-- NEXT_JS_LLM --> Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com> Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
Scaffolds a new API, `unstable_prefetch()`. It's only allowed in server code, so we ban it from being imported in the client. Implementation follows upstack. Intended to be merged together.
Implements `unstable_prefetch()`, which is intended for use in
`partialPrefetching`. `await unstable_prefetch()` excludes content from
the app shell -- it will only be available when using `prefetch={true}`
(speculative prefetch) or during navigations.
As a rule of thumb, `unstable_prefetch()` resolves whenever static
`params` would:
- in a static prerender
- but NOT the app shell extracted from it, which is param-less
- in a runtime prefetch (`prefetch={true}`)
- but NOT a runtime app shell, which is param-less
Note that `prefetch()` is URL data, so using it in an App Shell without
Suspense will trigger an instant insight.
### Implementation notes
`prefetch()` is treated like URL data, so it resolves in the
`PrefetchStatic/PrefetchRuntime` stages added in #96908. The
implementation is basically analogous to `unstable_navigation()` except
using different stages. i've considered abstracting them into one
implementation, but decided against that for now, we can deduplicate
later.
Error messages about URL data have not been updated to mention it yet --
we will do that as a follow up, along with docs.
`await prefetch()` does not count as a runtime data access, meaning that
it won't affect the static prefetch hint for a route. however `await
prefetch(); await cookies()` does deopt the route, because using a
speculative runtime prefetch would reveal more content. Note that this
may cause us to unnecessarily deopt a shell to runtime even if only the
speculative part of the content would be improved by a runtime request;
this is not a new issue, but it's something we should optimize.
Both https://nextjs.org/docs/app/api-reference/adapters, and https://nextjs.org/docs/pages/api-reference/adapters lists their children twice, once from the PR content, and another from next-site's rendering engine. Let's keep the next-site UI, as it lists each entry as a card with title + description.
…ife (#97653) Clarifying that: > - **`stale` from 30 seconds up to 5 minutes**: included in prerenders, but excluded from the route's [App Shell](/docs/app/glossary#app-shell). Means, 30 <= stale and stale < 5minutes
### What? Stabilizes the RSC poisoned-import error-overlay test for `proxy.js` without weakening or retrying its redbox assertion. ### Why? An initially broken proxy can emit the expected build error and then force a startup full reload. That reload can clear the overlay before the test begins observing it, causing an intermittent `Expected Redbox but found no visible one` failure even though validation worked. ### How? The proxy parameter now starts from a valid module and introduces the poisoned import only after the sandbox page has hydrated. This moves the assertion onto the live HMR path and removes the startup-reload race. Middleware and instrumentation retain their initial-compile setup because their error overlays are reliable there and instrumentation does not reliably surface this edit through Turbopack HMR. ### Verification - `pnpm test-dev-webpack test/development/acceptance-app/rsc-build-errors-poisoned-imports.test.ts` - `pnpm test-dev-turbo test/development/acceptance-app/rsc-build-errors-poisoned-imports.test.ts` - Proxy case repeated 5 times with Webpack and 3 times with Turbopack - Prettier, ESLint, and `git diff --check` <!-- NEXT_JS_LLM --> --------- Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com> Co-authored-by: Tobias Koppers <1365881+sokra@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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 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 : )