[pull] canary from vercel:canary - #1317
Merged
Merged
Conversation
## Summary
This is the behavior-preserving base of a four-PR stack that introduces
explicit prerender matching policy without coupling the foundational
refactor to the proposed API.
The build currently uses `PrerenderedRoute` values for two related but
distinct concepts:
- a logical request matcher that says which parameterized URL shapes the
route can handle
- a build-time render candidate that may or may not become a persisted
prerender artifact
A candidate is not guaranteed to be an output. It can be rendered only
to validate a shell, discarded, and still leave behind a matcher that
tells future requests to block.
The new relationship is:
```text
logical pathname matcher
-> zero or more render candidates
-> zero or more persisted artifacts
```
## Concrete example
Consider `/[top]/items/[bottom]`:
```ts
export function generateStaticParams() {
return [{ top: 't1', bottom: 'b1' }]
}
```
Static-path generation may consider three shapes:
| Shape | Purpose |
| --- | --- |
| `/[top]/items/[bottom]` | A generic shell candidate and logical
matcher |
| `/t1/items/[bottom]` | A shell after resolving `top` |
| `/t1/items/b1` | A concrete build-time prerender |
Suppose the generic candidate renders an allowed empty shell. The build
should discard that candidate artifact and use blocking behavior for the
generic matcher. It should not remove `/[top]/items/[bottom]` from the
valid matcher set, and it should not discard the concrete `/t1/items/b1`
artifact.
This is why the build needs two sets:
- route matchers, which describe valid request shapes
- prerender candidates, whose render results determine whether an
artifact is retained and can refine inferred fallback behavior
## Variants compatibility
Variants will make pathname-only candidate maps insufficient. Several
variant combinations can share `/t1/items/b1` as their logical pathname
while writing distinct artifacts under variant-specific output paths.
This PR keeps the route matcher keyed by logical pathname but retains
every candidate associated with it. Candidate finalization can therefore
evaluate each variant artifact independently without changing the route
tree's matcher set.
## Behavior preservation
This PR does not add a user-facing API or change `generateStaticParams`
semantics:
- a usable static shell remains a fallback prerender
- an allowed empty shell is discarded and represented by a blocking
matcher
- a route that requires a non-empty shell still fails validation
- unresolved matchers remain gated by route-level PPR support
- the most-specific shell continues to supply first-writer-wins metadata
such as prefetch hints
Render results can decide whether a candidate artifact is published and
can refine inferred matcher behavior, but they do not remove the logical
route matcher itself.
## Stack plan
1. **#97431 — model prerenders as render candidates:** land the
behavior-preserving matcher/candidate separation and post-render
finalization first.
2. **#97393 — add the experimental matcher API:** add `unstable_matcher`
and `unstable_generateMatcher`, policy aggregation, validation, and
local diagnostics.
3. **#97426 — test complex route shapes:** add test-only coverage for
catch-alls, optional catch-alls, root parameters, and parallel slots.
4. **#97427 — test foreground policy behavior:** add test-only coverage
showing blocking misses generate before responding while fallback misses
return the shared shell immediately.
This layering lets the internal model be reviewed and landed
independently of the API design. The upper test PRs validate the final
behavior without increasing the implementation diff.
## Verification
- `pnpm --filter=next types`
- `pnpm test-start-turbo
test/e2e/app-dir/sub-shell-generation/sub-shell-generation.test.ts`
- `pnpm test-start-turbo
test/e2e/app-dir/segment-cache/prefetch-inlining/prefetch-inlining.test.ts`
<!-- NEXT_JS_LLM -->
Fixes typos in the `analytics.tsx` link syntax in the two Segment example READMEs. Co-authored-by: Marcos Hernanz <96699542+marcoshernanz@users.noreply.github.com>
## Summary While reviewing the examples in the Next.js repository for potential improvements, I noticed a typo in the error message displayed when an unexpected error occurs. ## Changes - Corrected `"An unexpected error happened occurred:"` to `"An unexpected error occurred:"`. ## Testing No functional changes. This is a text-only fix. Co-authored-by: Marcos Hernanz <96699542+marcoshernanz@users.noreply.github.com>
### What? Fix grammar issues in the "Linking and Navigating" guide. ### Why? This sentence had a few grammar issues: - "makes" should be "make" - "a server-rendered apps" should be "server-rendered apps" - "it enables" should be "they enable" ### How? Updated the sentence in `docs/01-app/01-getting-started/04-linking-and-navigating.mdx` to correct grammar and improve subject-verb agreement. --------- Co-authored-by: Marcos Hernanz <96699542+marcoshernanz@users.noreply.github.com>
…6335) ## Summary This PR improves the accessibility of the `with-apivideo-upload` example by associating form labels with their corresponding form controls using the `htmlFor` attribute. ## Changes - Added `htmlFor="link"` to the "Play button color" label. - Added `htmlFor="linkHover"` to the "Buttons hover color" label. - Added an `id` to the "Hide controls" checkbox and associated its label using `htmlFor`. ## Why Associating labels with their corresponding form controls improves accessibility by: - Allowing screen readers to correctly announce form labels. - Enabling users to focus or toggle controls by clicking their labels. - Following HTML and WCAG best practices for accessible forms. ## Before - Labels were visually displayed but were not programmatically associated with their respective inputs. ## After - Each label is associated with its corresponding form control via `htmlFor` and `id`, improving accessibility without changing functionality. ### Testing - Verified that clicking each label focuses or toggles the associated control. - No visual changes. Co-authored-by: Marcos Hernanz <96699542+marcoshernanz@users.noreply.github.com>
…#97456) ## What Vercel's **Edge Config** product is now **Global Config**. This updates the two stale-name occurrences flagged in the redirecting guide. The URL was already migrated in #96723 (`/docs/edge-config/get-started` → `/docs/global-config/get-started`), but that pass only rewrote link targets — the visible product name and the SDK import in the code samples still said `Edge Config` / `@vercel/edge-config`, so the page read *"Vercel's Edge Config"* while linking to the Global Config docs. ## Changes `docs/01-app/02-guides/redirecting.mdx`, in *Managing redirects at scale → Creating and storing a redirect map*: | | Before | After | | --- | --- | --- | | Prose | Vercel's [Edge Config] | Vercel's [Global Config] | | `proxy.ts` / `proxy.js` samples | `import { get } from '@vercel/edge-config'` | `import { get } from '@vercel/global-config'` | The link target, the neighbouring [Redis](https://vercel.com/docs/redis) link, and the surrounding sentence structure are unchanged. ## Why the package import changed too The renamed package is published and is the same library — `@vercel/global-config@1.5.1`, from `vercel/storage` at `packages/global-config`, matching `@vercel/edge-config@1.5.1` — and it exports the same `get`. Vercel's own [Global Config quickstart](https://vercel.com/docs/global-config/get-started) now uses `import { get } from '@vercel/global-config'`. Leaving the old specifier would have left the sample importing a legacy package name on a page that calls the product Global Config. `@vercel/edge-config` is not yet formally deprecated on npm, so this is a naming-consistency change rather than a fix for broken code. ## Both flagged pages Two docs paths were flagged — `/docs/app/guides/redirecting` and `/docs/pages/guides/redirecting` — but they share one source. `docs/02-pages/02-guides/redirecting.mdx` is a generated stub (`source: app/guides/redirecting`, carrying the *DO NOT EDIT* banner), and the affected paragraph is not wrapped in `<AppOnly>`/`<PagesOnly>`, so it renders on both. Editing the App Router source fixes both pages; no separate edit to the Pages file is needed or allowed. ## Verification - `grep -rn "Edge Config\|edge-config" docs/` → no matches remain. - `prettier --check` and `alex` pass on both files; the pre-commit `lint-staged` (prettier + eslint) pass ran clean. - `https://vercel.com/docs/global-config/get-started` → `200`; the old `/docs/edge-config/get-started` → `308`, confirming the link already points at the final target. Docs-only change; no code or tests affected. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com> Co-authored-by: Rich Haines <22930449+molebox@users.noreply.github.com>
## Summary While reviewing the examples in the Next.js repository for potential improvements, I noticed a redundant `justify-content` declaration in the `.submit` styles. ## Changes - Removed the redundant `justify-content: flex-end` declaration. - Kept `justify-content: space-between`, which overrides the previous declaration. ## Testing No functional changes. This is a CSS cleanup only. Co-authored-by: Marcos Hernanz <96699542+marcoshernanz@users.noreply.github.com>
### What? Documents the `pagination` metadata field in the `generateMetadata` API reference. ### Why? The `Metadata` type supports `pagination.previous` and `pagination.next`, but the Metadata Fields documentation did not list the field. Fixes #83264 ### How? Adds a `pagination` section with an example and the generated `<link rel="prev">` / `<link rel="next">` output. ### Tests - `pnpm prettier --check docs/01-app/03-api-reference/04-functions/generate-metadata.mdx` - `pnpm lint-eslint docs/01-app/03-api-reference/04-functions/generate-metadata.mdx` - `git diff --check HEAD~1..HEAD` <!-- NEXT_JS_LLM_PR -->
…etected changes to node_modules (#96116) Previously, we were debouncing update by sleeping 1ms at a time on macos and windows, and 10ms at a time on Linux. During a slow `pnpm install`, or a `git checkout`, this could cause us to do a bunch of extra throwaway work. Changes: - Increase the debounce interval to a consistent 10ms everywhere. This should still be small enough that it's not noticable on macos or windows. - If an event touches `node_modules`, there's a good chance that a package manager is running and many other files will be modified, so extend the batch deadline by 200ms instead of 10ms. - Because there's a chance that the batch deadline could get extended indefinitely (this was always possible, just more likely now) include a compilation event that gets logged after 5 seconds.
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.
7 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 : )