* fix: align app router navigation parity
* fix(app-router): preserve canonical RSC and hard-nav semantics
App Router RSC requests now keep the route pathname shape when adding _rsc. Stripping a trailing slash made trailingSlash routes fetch a non-canonical URL and let the server redirect the client-side RSC request back to the slash form.
The MPA navigation scheduler also keys pending hard navigations by both href and history mode so a later replace does not reuse an earlier push closure. Redirect handling keeps the global browser bridge out of passive server rendering while retaining client-side redirect recovery.
Adds focused regression coverage for trailingSlash RSC requests, same-href push-to-replace hard navigation, and client redirect guard loops. Updates existing navigation observers to the canonical route URL plus _rsc transport.
* fix(app-router): stabilize action and prefetch parity
* fix(app-router): reset MPA dedupe after bfcache restore
A bfcache-restored App Router document can keep the scheduler's last pending hard-navigation marker after the external navigation already left the page. Reissuing the same href and history mode then entered the suspended MPA path without scheduling another location change.
Expose a scheduler reset for the browser lifecycle boundary and call it on persisted pageshow events. Cover the scheduler contract so the same external navigation can run again after reset.
* fix(app-router): isolate redirect bridge from passive boundaries
Unhandled client redirect recovery currently lives inside every RedirectBoundary, while Pages Router params fallback can keep stale App Router params after an App-to-Pages transition. That makes passive boundaries own browser runtime wiring and lets stale app params win over live Pages Router params.
Move the unhandled redirect bridge into BrowserRoot under AppRouterContext, keep RedirectBoundary passive, and prefer live Pages Router params when that compat context exists. Add an App-to-Pages navigation regression fixture.
* fix: extract shared decodeRedirectError helper, rename stale test
- Add decodeRedirectError() to shims/navigation.ts as the single
source of truth for parsing redirect error digests
- Replace three private helpers in error-boundary.tsx with shared
decodeRedirectError() call
- Replace inline digest parsing in AppRouterRedirectBridge with
shared decodeRedirectError() call (fixes unsafe decodeURIComponent)
- Rename test that claimed to test redirect() but actually tests
<Link> navigation
* refactor: eliminate unnecessary type assertions
- isRedirectError: use in-narrowing instead of as-casts
- AppRouterRedirectBridge: remove as after guard already narrows
- RedirectErrorBoundary: inline digest access, use in for handled check
* ci: retrigger checks
* fix: emit noindex for Forbidden/Unauthorized boundaries, extract retryScrollTo helper
* docs: clarify decodeRedirectError comment about defensive join
* fix(pages-router): run _document.getInitialProps with renderPage enhancers
Refs #1468.
Custom `pages/_document.tsx` files that override `getInitialProps` and
call `ctx.renderPage({ enhanceApp, enhanceComponent })` to wrap the
App/Component tree — the standard styled-components / emotion pattern
for SSR style collection — silently no-op'd. The shim type advertised
`renderPage`, but the SSR pipeline never invoked `getInitialProps` with
a real `renderPage`, so the enhancers never ran and `<Document>` never
saw the wrapped tree.
This wires the Pages Router `_document.getInitialProps` contract
through both the prod (`renderPagesPageResponse`) and dev
(`streamPageToResponse`) pipelines:
- A new `enhancePageElement(opts)` option exposes the App/Component
separation needed to apply `enhanceApp` / `enhanceComponent` from
the user's renderPage call. `pages-server-entry.ts` and the dev
server both wire it up to wrap `App({ Component, pageProps })`.
- When `DocumentComponent.getInitialProps` is defined, we invoke it
with a minimal `DocumentContext` shim that includes `renderPage` and
`defaultGetInitialProps`. `renderPage` rebuilds the React tree via
`enhancePageElement`, drains the React stream to a string, and
returns `{ html, head }`.
- If renderPage was called, the streaming body fallback is replaced
with the captured `html` so `_document` sees a complete body (matches
Next.js's `loadDocumentInitialProps` behaviour). Any `styles` element
returned by getInitialProps is rendered to HTML and appended to the
document head.
- If `getInitialProps` throws, returns a non-string `html`, or never
invokes renderPage, we fall through to the existing streaming path —
no user-visible regression for the common case where `_document` has
no `getInitialProps`.
Adds a focused regression in `tests/pages-page-response.test.ts` that
confirms `enhanceApp` and `enhanceComponent` both run and that the
enhanced tree appears in the rendered body. Mirrors
`.nextjs-ref/test/development/basic/styled-components/pages/_document.js`
and `.nextjs-ref/packages/next/src/server/render.tsx`
(`loadDocumentInitialProps` / `enhanceComponents`).
Test plan:
- `pnpm test tests/pages-page-response.test.ts`
- `pnpm test tests/document.test.ts tests/head.test.ts tests/shims.test.ts`
- `pnpm test tests/pages-router.test.ts`
- `pnpm test tests/entry-templates.test.ts`
- `pnpm run check`
* refactor(pages-router): consolidate _document renderPage onto shared helper
Address review feedback on the _document.getInitialProps + renderPage
contract:
- Extract a single shared runDocumentRenderPage() helper in
pages-document-initial-props.ts, used by both the prod
(pages-page-response.ts) and dev (dev-server.ts) SSR pipelines. The
duplicated inline implementation in dev-server.ts is removed (-86/+38).
- withScriptNonce now lives in one place (the shared helper); both
callers' enhancePageElement return the bare enhanced tree.
- Remove dead headFromDocument (returned but never consumed).
- Drop the redundant React.Fragment wrapper around enhancedElement.
- Reconcile with #1677's loadUserDocumentInitialProps: getInitialProps is
invoked at most once. A discriminated result (skipped/consumed/rendered)
signals when the fast path must be skipped so getInitialProps is not
called twice (which would re-throw a user error as a 500).
- Add edge-case tests: styles returned, getInitialProps throws (clean
fallback), renderPage never called.
* refactor(pages-router): address re-review nits on shared renderPage helper
- runDocumentRenderPage now skips the base-shim getInitialProps via the
BASE_GET_INITIAL_PROPS identity check (mirrors loadUserDocumentInitialProps)
so an unoverridden _document stays on the cheap fast path.
- Dev now forwards { pathname, query, asPath } as the DocumentContext, matching
the prod pipeline's parity.
- Add a test for renderPage being called but the underlying stream render
throwing (falls back cleanly to the streaming render).
* fix(pages-router): drop unused RunDocumentRenderPageResult export, document pageProps capture
- Remove the `export` on the internal `RunDocumentRenderPageResult` type
(knip flagged it as an unused export; it is only used as the helper's
return type within the same module).
- Document why `enhancePageElement` captures `pageProps` from the closure
rather than receiving it as a parameter (it is invoked once per request
with a single `pageProps`; only the enhancers vary).
* refactor(pages-router): address bonk re-review nits
- dev-server enhancePageElement: document the pageProps closure capture to
mirror the prod entry's comment
- prod renderStylesToString: render the collected styles fragment with the
plain stream renderer instead of the full <Document> shell renderer
- lazify pageElement construction so it is only built on the streaming path
(never used when renderPage already produced the body)
* fix(shims/head): keep charset/viewport defaults on client hydration
The Pages Router next/head client sync (syncClientHead) removed every
[data-next-head] element and rebuilt the projection from only the user
<Head> children, omitting defaultHead() (charset + viewport). After the
first <Head> mounted on the client, the server-rendered charset and
viewport meta tags were stripped and never re-added.
PR #1677 seeded defaultHead() into the SSR collector (getSSRHeadHTML)
but not the client path. Next.js's reduceComponents() always concatenates
defaultHead() on both server and client, so the defaults must survive
hydration here too.
Seed defaultHead() into the client reduce, mirroring the SSR path. Users
can still override via key="charset" / key="viewport" through the same
dedupe pipeline.
Adds a regression test exercising the client projection with a minimal
DOM double (the repo has no jsdom).
* fix(shims/head): reconcile client head in place to preserve SSR order
The client sync still wiped every [data-next-head] node and re-appended
the projection, which moved the SSR-emitted charset/viewport/title tags to
the end of <head> (after the modulepreload/script links) and caused DOM
churn/flicker on every <Head> update.
Mirror Next.js's head-manager.ts updateElements(): diff the desired tags
against existing ones via isEqualNode(), leave matches untouched in their
original DOM position, append only genuinely new tags, remove stale ones,
and prepend a newly-created <meta charset> so it stays first.
Extends the regression tests with a richer DOM double asserting node reuse,
order preservation, insertion, removal, and charset-first behavior.
* test(shims/head): client-side override coverage; document divergences
Address non-blocking review notes from /bigbonk:
- Add a client-side test asserting a user key="viewport" overrides the
default viewport on _syncClientHead (mirrors the SSR override test),
locking in the dedupe-precedence parity claim.
- Document the deliberate charset prepend if/else divergence from Next.js's
head-manager.ts (which prepends then unconditionally appendChilds).
- Document the <title> reconciliation divergence (Next.js sets document.title
directly; we reconcile title like any tag — cosmetic only).
- Reconcile issue references to #1569 / #1677 in the client describe block.
Concurrent `Router.push` calls (or back-to-back `<Link>` clicks) to the
same gSSP route each fired their own `_next/data/<id>/<page>.json` fetch.
The Next.js parity test asserts `hit: 1` after 4 rapid navigations to a
slow page; vinext was producing `hit: N`.
Add a module-scoped in-flight Promise cache keyed by the resolved data
URL, mirroring `fetchNextData()`'s `inflightCache` in
`packages/next/src/shared/lib/router/router.ts`. Concurrent callers share
one `fetch()` invocation and each receive a cloned Response. Entries
self-evict on settle so the next navigation re-fetches fresh.
The shared fetch deliberately ignores per-caller `AbortSignal`s: stale
navigations are already detected via `_navigationId` + `assertStillCurrent()`
checkpoints after the await, and aborting the shared request on behalf of
one superseded caller would destroy the dedup gain for every other
concurrent caller. Pre-await abort still surfaces so callers see the
documented `NavigationCancelledError` / `AbortError` when supersession
happened before the fetch was even attempted.
Wired into both `navigateClientData()` (the JSON fast path) and
`resolveMiddlewareDataRedirect()` (the soft-redirect probe).
* fix(shims/head): match Next.js charset/viewport order and merge _document.getInitialProps head (#1569)
Pages Router head emission did not match Next.js's canonical order
(`<meta charset>` then `<meta viewport>` then user tags, all with
`data-next-head=""`) and ignored head tags returned from a user
`_document.getInitialProps()`.
- `next/head` shim now seeds `defaultHead()` (charset + viewport) into
the SSR collector before user tags, mirroring `defaultHead()` in
`next/src/shared/lib/head.tsx`. They flow through the same dedupe
pipeline so users can still override via `key="charset"` /
`key="viewport"`.
- Serialised attribute names follow HTML conventions
(`charSet` -> `charset`, `httpEquiv` -> `http-equiv`, etc.), matching
Next.js's `test/e2e/next-head/index.test.ts` exact-string assertion.
- `next/document` shim no longer hardcodes charset/viewport in `<Head>`
(those defaults now flow from `next/head`); fallback HTML shells in
`dev-server.ts` and `pages-page-response.ts` likewise drop the
duplicates.
- New `setDocumentInitialHead()` accessor and ALS-backed state lets the
SSR pipeline forward head tags returned by user
`_document.getInitialProps()` into the same dedupe pipeline as
`next/head` children. Both the dev server and the prod
`renderPagesPageResponse` invoke `_document.getInitialProps()` when
present and pass the result through.
Adds focused regression coverage in `tests/head.test.ts` for ordering,
default attribute serialisation, key-based overrides, and the
`_document.getInitialProps()` merge path.
Refs #1569.
* fix(pages-router): address review feedback on _document head merge
- Extract shared `callDocumentGetInitialProps` helper under
`server/document-initial-head.ts` so both `dev-server.ts` and
`pages-page-response.ts` go through the same code path. The previous
duplicated try/catch blocks drifted independently and were the kind of
runtime-behavior that AGENTS.md says should live in a helper.
- Skip the call when `DocumentComponent.getInitialProps` is still the
unmodified default inherited from vinext's `next/document` shim.
Comparing against the captured base reference (`DEFAULT_GET_INITIAL_PROPS`)
distinguishes a user override from the default — extending `Document`
without overriding the method inherits the same static function, so
invoking it on every render is wasted work.
- Use `jsxAttrToHtml` on the client-side `_applyHeadPropsToElement` path
so `httpEquiv` is set as `http-equiv` rather than `httpequiv`
(lowercased by `setAttribute`). Matches the SSR output and prevents a
hydration mismatch when SSR emits the hyphenated form.
- Update stale `tests/document.test.ts` Head assertions: the shim's
`<Head>` no longer hardcodes charset/viewport — those flow through
`next/head`'s `defaultHead()` so the dedupe pipeline handles them.
PR #1701 added `resolve.noExternal: true` while loading a TypeScript
next.config so a baseUrl-local file could shadow an installed package of the
same name. That de-externalizes every installed package and forces it through
Vite's module runner, which breaks CJS config plugins that call `require` /
`require.resolve` at runtime — e.g. `@next/mdx`, which failed the
app-router-playground production build with "require is not defined".
This was not caught pre-merge because deploy-examples is skipped for fork PRs.
Drop the blanket `noExternal: true`. Installed packages stay externalized (so
CJS config plugins keep working), and the native Vite 8 `resolve.tsconfigPaths`
resolver still resolves baseUrl-local bare imports that have no installed
package of the same name (the real Next.js tsconfig-extends fixture). The only
behavior we give up is shadowing an installed package with a baseUrl-local file
of the same name, which no Next.js fixture exercises.
- Update the shadowing test to assert the installed package wins.
- Add a regression test for an @next/mdx-style CJS plugin that calls
`require.resolve` at runtime (red before this change).
- Document the package-precedence behavior in the README limitations entry.
* fix(config): resolve next.config baseUrl imports from tsconfig
next.config.ts could resolve tsconfig paths aliases but not bare imports covered by compilerOptions.baseUrl. This broke configs that inherit baseUrl through tsconfig extends and import local modules such as "bar" from next.config.ts.
Carry the effective baseUrl out of the tsconfig reader and add a narrow Vite runner resolver for bare specifiers so local files resolve before normal package fallback. Add a regression ported from the Next.js tsconfig-extends deploy fixture.
* fix(config): preserve baseUrl priority over packages
next.config.ts imports that matched both a local tsconfig baseUrl target and an installed package resolved to the package first. That violated the TypeScript and Next lookup order where baseUrl local resolution wins before package fallback.
Vite's module runner externalized installed bare packages before resolveId hooks ran, so the baseUrl resolver only handled missing packages. Keep config imports inside the resolver pipeline, run the baseUrl resolver before package resolution, and scope it to project-owned importers so package dependencies are not rewritten through the app baseUrl.
Adds focused regression coverage for local-over-package shadowing, package fallback, node_modules importer isolation, and existing CJS/ESM package imports from next.config.ts.
* fix(config): keep baseUrl lookup scoped to TypeScript configs
next.config.mjs could inherit TypeScript baseUrl package shadowing because the config runner noExternal override and baseUrl resolver were enabled for every config file type. That leaked Next's TypeScript config transpilation semantics into non-TypeScript config loading.
Gate the baseUrl resolver and noExternal runner override behind TypeScript config extensions while keeping existing alias loading behavior unchanged. Add a regression for mjs package shadowing and update the tsconfig helper comment to name baseUrl explicitly.
* refactor(config): resolve next.config baseUrl via native Vite 8 tsconfigPaths
Replace the hand-rolled tsconfigBaseUrlResolverPlugin with Vite 8's native
resolve.tsconfigPaths (oxc-resolver tsconfig: 'auto'), which already mirrors
Next.js's SWC paths + baseUrl handling: follows extends, resolves baseUrl-local
bare imports before package fallback, and scopes the app baseUrl to
project-owned importers via per-importer tsconfig discovery.
Gate it behind the existing Vite-major check (matching index.ts). Vite 7 has no
native equivalent, so baseUrl bare imports in next.config.ts are a documented
Vite 7/8 capability gap; paths aliases still work on both via resolve.alias.
Extract getViteMajorVersion into utils/vite-version.ts so next-config.ts and
index.ts share one detection path without a circular import.
---------
Co-authored-by: James <james@eli.cx>
PR #1697 added a client-environment guard that throws when a module
imports "server-only", to match Next.js rejecting server-only from
client-reachable code. But Server Actions modules ('use server') live in
the server/action layer, not the client layer, and Next.js explicitly
allows them to `import 'server-only'` (see
test/e2e/app-dir/actions/app/client/actions.js). Because the client
bundle holds references used to invoke the actions, the action module
enters the client graph and the guard threw, failing the entire client
build.
This false positive broke 136 deploy-suite tests across the actions and
app-basepath suites. Exempt modules with a top-level "use server"
directive so genuine client modules are still rejected.
Adds a regression test that builds an App Router 'use server' module
importing server-only, alongside the existing negative test proving
client modules are still rejected.
App Router metadata routes returned their generated response before the middleware response context was merged. That let static metadata defaults such as Cache-Control: public, max-age=0, must-revalidate overwrite a middleware Cache-Control header for app/favicon.ico.
Apply the same middleware response-header and status merge used by other App Router response paths before returning metadata route responses, and cover the upstream Next.js no-duplicate-headers fixture.
* feat(skip): add layout safety observation foundations
Introduce the per-layout observation primitives that later slices need
to decide whether retained static layouts can be reused. This slice
adds the machinery only; nothing reads the observations yet, so
behavior is unchanged.
- app-layout-param-observation: per-layout completeness, param keys,
structural scope, finite revalidate, request API, cacheLife, cache
tag, cacheable fetch, dynamic fetch, and unstable_cache observation
tracker.
- app-page-probe: bounded React server subtree probe that walks
layout-returned children including memo, forwardRef, and React.lazy
wrappers, enforces depth and node limits, and refuses single-use
iterable children.
- shims: thenable params observer for sync, await, destructure, and
enumeration. Cache, fetch, and unified request context record
unstable_cache, cacheable fetch, and request-scoped observation
state.
- app-page-params: structural segment-param scope so empty optional
catch-all targets are not treated as param-free downstream.
No skip transport behavior. Later slices wire the planner, manifest,
and encoder onto these observations.
* fix(skip): address review feedback on observation foundations
- Add currentFetchSoftTags reset in runWithIsolatedProbeDependencies to prevent soft tag leak from parent scope (matches runWithFetchCache isolation)
- Replace unnecessary JSON.stringify in cacheLife check with direct null comparison
- Add comment documenting intentional omission of markProbeComplete on probe errors (keeps completeness as unknown, safe fallback to render-and-send)
* fix(skip): record cacheable-fetch observation synchronously before first await
The patched fetch deferred observation and tag collection past
await buildFetchCacheKey(). If a layout probe started a cacheable
fetch and returned synchronously without awaiting it, the probe
snapshot would see cacheableFetchCount: 0 -- a false proof that
could let the skip planner reuse a stale retained layout.
Move observation and tag recording before the first await in the
cacheable branch. If key generation later fails and the fetch falls
back to dynamic, recording both is conservative (false unsafe costs
performance, not correctness).
Add an integration test that exercises the real patched fetch shim
without mocks to verify synchronous observation capture.
* fix(test): remove polluting fetch restore and catch background promise
Do not restore globalThis.fetch in test cleanup. ensureFetchPatch
sets a global _PATCH_KEY guard; restoring fetch without clearing
that marker makes later calls skip reinstallation silently.
Catch the background fetch promise inside the probe so the patched
fetch continuation (cache lookup, network fetch) cannot produce an
unhandled rejection after the synchronous assertions complete.
* chore: empty commit to trigger CI
* chore: empty commit to trigger CI
* fix(pages): preserve import.meta.url source paths
Pages Router production bundles previously left direct import.meta.url expressions for the bundler to evaluate from generated output. Server renders could expose dist/server/entry.js, and prerendered Pages output could miss the client entry needed for hydration to replace the server value with the Turbopack-style browser source URL.
The fix rewrites direct import.meta.url reads in user modules to source-file URLs at transform time, keeps new URL asset bases intact, and loads the Pages client entry from the build manifest for Node production and prerender servers.
Regression coverage ports the Next.js import-meta deploy test, including the prerender and hydrated browser path.
* fix(tests): run import.meta browser coverage in e2e
The import-meta regression test launched Playwright from a Vitest integration shard. That shard does not install Playwright browser binaries in CI, so it failed before exercising the runtime behavior.
Move the browser assertion into the existing pages-router-prod Playwright project, keep the lower-boundary server and client chunk assertions in Vitest, and cache the import-meta plugin root paths after an early source-text bailout to address review feedback.
* refactor(import-meta-url): canonicalize each module once per transform
The transform path canonicalized the same module id twice: once in the
eligibility check and again when computing the replacement value, so every
rewritten module paid for two fs.realpathSync.native() syscalls.
The eligibility check now returns the canonical id and threads it through to
the value computation, leaving a single realpath per module.
Also widens the extension match to .cts/.mts/.cjs and documents that the
new URL() skip only covers the bare URL identifier, matching Vite's own
asset-detection scope.
* test(pages): drop unrelated prerender from top-level-await setup
The top-level-await production test ran runPrerender in its setup, but the
assertions pass identically whether the routes are prerendered or rendered on
demand. The step added unrelated build work to a test that is not about
prerendering or client-entry injection.
* fix(pages): share client entry fallback
* fix(import-meta-url): address PR review feedback
- Handle ChainExpression (import.meta?.url) in new URL() asset-detection
skip so the optional-chain variant preserves Vite asset resolution
- Add explicit ChainExpression check in visit() to avoid fragile
reliance on coincident inner-node start/end ranges
- Add test for new URL('./file', import.meta?.url) preservation
- Fix decodeHtmlText entity ordering (& before ") in both
unit and E2E test helpers
- Add doc comments: excluded prefixes rationale, node_modules
early-exit optimization intent
* fix(pages): select client entry by marker in build manifest
findClientEntryFileFromManifest returned the first chunk flagged
isEntry, but a client build can emit several entry chunks (client
entry plus instrumentation/middleware) and manifest order is not
guaranteed. The on-disk fallback already disambiguates by the
vinext-client-entry / vinext-app-browser-entry marker; apply the
same check to the manifest path so both lookups agree, falling back
to the first entry only when nothing is marked.
* refactor(pages): address review feedback on client-entry/import-meta-url
- prod-server: hoist findClientEntryFile out of the manifest if/else
since it already handles a missing manifest via the on-disk fallback
- import-meta-url: document the two known limitations (destructured
access, aliased new URL() base) that match Vite's own behavior
- import-meta-url: drop the dead visit(value.callee) for new URL() —
the callee is always the bare URL identifier
---------
Co-authored-by: James <james@eli.cx>
MemoryCacheHandler used an unbounded Map for default ISR/fetch/cache
storage. Add a Next-style memory cap with approximate byte sizing and
least-recently-used eviction.
Behavior:
- default max size is 50 MiB, matching Next.js cacheMaxMemorySize default
- cacheMaxMemorySize: 0 disables default memory storage
- entries larger than the configured cap are not stored
- get() refreshes LRU order
- tag invalidation metadata is capped to 10k entries
Wire next.config.js cacheMaxMemorySize into both App and Pages generated
entries via configureMemoryCacheHandler(). Add focused unit coverage for
LRU eviction, get() recency refresh, and disabled storage.
Pages Router ISR cache entries were keyed only by pathname. With i18n
domain routing, the same pathname can render different content depending
on the matched domain and default locale. A cache entry created for one
domain could be reused for another domain.
Add an i18n cache variant to the Pages ISR key when i18n is configured:
- domain:<domain> for matched domain-locales
- locale:<locale> for locale-prefix/default-locale routing
Adds a Pages i18n production fixture page with getStaticProps +
revalidate and verifies example.fr and example.com maintain separate
ISR entries for the same pathname.
Match Next.js handling for the server-only marker: imports are allowed
from App Router Server Components and middleware/server targets, but
client-reachable modules must fail instead of silently resolving the
empty shim.
Add an AST-based client-environment transform guard so comments or
string literals do not false-positive. The existing middleware test
continues to prove server-only remains allowed from middleware graphs,
and the new Pages Router fixture mirrors Next.js's compiler error test
for server-only imported from a Pages client graph.
* feat(skip): add static layout reuse proof model
Add the proof/planner vocabulary that decides whether a verified
static layout entry from a client reuse manifest is reusable.
Nothing renders this decision yet, so no payload is omitted.
- skip-cache-proof: static layout reuse planner with per-entry budget,
exact artifact-compatibility check, payload hash, route id, and
invalidation proof. Preserves rejection traces. Returns the existing
disabled disposition when not authorized.
- static-layout-client-reuse-proof: static layout payload hash, route
id, and artifact compatibility helpers used by the planner.
- client-reuse-manifest: extends the rejection code union with the
layout-safety rejection codes the planner emits, and adds the
enabled skip disposition variant so future slices can carry an
authorized result without retyping the union.
This slice is the proof vocabulary only. The planner is callable but
not invoked from the render path; encoder behavior is unchanged.
* fix(skip): address review — budget counts all wire entries, default enforcement, triple-walk justification, hash stability comment, forward declarations comment, absent-manifest test
* fix(skip): replace as const with explicit return type annotation
* fix(skip): replace as const with ProofFieldPair type alias
* fix(skip): address copilot review — pairs serialization, budget disambiguation, skip-ineligible tracking, compatibility-bridged test
* fix(skip): remove routeId from renderEpoch, bind verifier entryId, add sibling-route test
* fix(skip): exclude routeId from payload hash, add end-to-end sibling-route proof test
* chore(skip): move proof fields to artifact-compatibility, rename to maxWireEntriesToVerify, short-circuit exact check
* chore(skip): address review comments — fix hash comment, remove redundant guard, drop budget alias, dedupe exact-compatibility check
* feat(check): recognize Sparkle experimental flags in CONFIG_SUPPORT
* test(check): add tests for Sparkle experimental flags
* feat(config): warn when cachedNavigations is set without cacheComponents
* test: address ask-bonk review on cachedNavigations tests
- Remove redundant mockRestore() calls (afterEach handles it)
- Add negative test cases for cachedNavigations not set / false
- Match existing swcEnvOptions test style (warn.mock.calls.find())
Next.js's loader-tree dynamic-segment tuple includes a `staticSiblings`
list (the static sibling segment names at the dynamic URL level) so the
client router can decide whether a cached prefetch of a dynamic route
can be reused when navigating to a static sibling URL. vinext was not
emitting this metadata, so the static-siblings e2e suite failed all four
substring assertions against the RSC payload.
This change:
- Adds `computeAppRouteStaticSiblings(allRoutes, matchedRoute)` to the
app route graph. Ported from Next.js's `getStaticSiblingSegments` in
the next-app-loader. For each dynamic URL level in the matched route,
it collects the names of routes whose corresponding segment is
static and whose preceding URL prefix matches literally.
- Pre-computes the result per route at entry-generator time
(`buildRouteEntries` in app-rsc-manifest) so the runtime carries a
static list instead of recomputing for every request.
- Threads it through `AppPageRouteWiringRoute` and emits it on the
wire as a new `__staticSiblings` metadata key when non-empty. The
Flight serializer already spreads the elements record into the
outgoing payload, so the key lands on the RSC response unchanged.
The new `tests/app-static-siblings.test.ts` covers the helper's
sibling-collection rules (cross-route-group, same-directory, deeply-
nested non-leak, dedup) and asserts `buildAppPageElements` emits
`__staticSiblings` on dynamic routes and omits it when empty — matching
the four sub-cases of Next.js's static-siblings e2e suite.
Ported from Next.js:
test/e2e/app-dir/static-siblings/static-siblings.test.ts
Refs cloudflare/vinext#1328
Refs #1517.
The vinext `next/script` shim ignored the `stylesheets` prop, so an
`<Script src="/x.js" stylesheets={['/x.css']} />` element emitted only the
`<script>`/preload and silently dropped the associated stylesheet (and
worse, leaked the prop onto the rendered `<script>` as a `stylesheets="..."`
attribute on the beforeInteractive branch).
Mirror the App-Router branch of Next.js's component
(`.nextjs-ref/packages/next/src/client/script.tsx:309-313` and
`:48-59`):
- SSR: call `ReactDOM.preinit(href, { as: 'style' })` for each entry —
React Float hoists `<link rel="stylesheet">` into `<head>`.
- Client load path (`loadClientScript` + `handleClientScriptLoad`): same
preinit preferred; fall back to direct `document.head.appendChild` of
`<link rel="stylesheet">` when `ReactDOM.preinit` is unavailable.
- Destructure `stylesheets` out of `rest` everywhere so it never lands
as an attribute on the emitted `<script>`.
- Add `stylesheets` to the `RESERVED` set used by the hoisted-script
attribute collector for inline beforeInteractive scripts.
Scope: stylesheets prop only. Nonce propagation (the other half of #1517)
is already handled across SSR (`buildBeforeInteractiveScriptProps`,
`ReactDOM.preload`) and client (`loadClientScript`) paths — see the
existing "Script nonce resolution" suite. Bootstrap-script preinit is a
separate, larger change tracked under #1328.
Tests: extend `tests/script.test.ts` with a `Script stylesheets prop`
suite covering SSR emission, multi-entry lists, prop leakage on the
rendered `<script>`, omitted/empty lists, and the imperative
`handleClientScriptLoad` path.
Closes the Pages Router parity gap noted as a follow-up in #1206. When
`unstable_catchError`'s boundary is rendered under the Pages Router,
`unstable_retry()` now throws Next.js's verbatim error message
("`unstable_retry()` can only be used in the App Router. Use `reset()`
in the Pages Router.") instead of calling App Router's `refresh()`
(which is a no-op there and leaves the user stuck on the error).
Detection mirrors Next.js's own implementation in
`packages/next/src/client/components/catch-error.tsx`: the inner class
component reads `RouterContext` via `static contextType`. The wrapper
stays a pure JSX factory so existing introspection-style unit tests
that invoke it as a bare function continue to work.
Regression test ported from
`test/e2e/app-dir/catch-error/catch-error.test.ts` —
"should throw when unstable_retry is called on Pages Router".
When a server action id resolved from request headers carries the
`#<exportName>` suffix (e.g. `/app/foo.ts#bar`), `loadServerAction()`
splits the id at `#` and calls `requireModule(file)` with the module
path only. `@vitejs/plugin-rsc`'s reference-validation virtual module
therefore emits `[vite-rsc] invalid server reference '/app/foo.ts'`,
omitting the `#<exportName>` portion. The previous match in
`isServerActionNotFoundError` compared the full actionId against the
Vite error string, so missing/stale references surfaced as a generic
500 instead of the Next.js-compatible 404 with the
`x-nextjs-action-not-found` header.
Also accept the pre-`#` module-path form for both the dev-time
`[vite-rsc] invalid server reference '<id>'` and prod-time
`server reference not found '<id>'` error shapes.
Adds a focused unit test reproducing the dev-mode case and integration
tests asserting that throwing `notFound()` from a server action returns
404 (both fetch and progressive form paths), porting fixture from
Next.js: test/e2e/app-dir/actions/app/server/form.js.
* fix(app-router): cache pages with revalidate=Infinity/false (#1487)
App Router pages exporting `revalidate = Infinity` (or `revalidate = false`,
which resolves to Infinity in segment config) were re-rendered on every
request: the HTML response policy returned `shouldWriteToCache: false`, and
the cache-write policy rejected non-finite revalidate values outright. The
downstream Cache-Control header was correct (1y s-maxage), but vinext itself
never served identical bytes for repeat requests inside the same process.
This change treats `revalidate = Infinity` as "cache indefinitely" rather
than "never write to cache":
- `resolveAppPageHtmlResponsePolicy` now writes the cached HTML/RSC bundle
in production and reports `MISS` on first render, matching the standard
ISR write flow. Dev mode continues to emit `STATIC` with no cache write.
- `resolveAppPageCacheWritePolicy` accepts `Infinity` as a valid revalidate
interval; only `null`, `NaN`, and non-positive values reject the write.
The MemoryCacheHandler (used by tests and as the default) already handles
Infinity correctly: `revalidateAt = now + Infinity` keeps the entry fresh
forever until `revalidatePath`/`revalidateTag` invalidates it.
Adds two production-server regression tests:
- `export const revalidate = 60` returns HIT with identical timestamp on
the second request (covers the standard finite case).
- `export const revalidate = Infinity` returns HIT with identical timestamp
on the second request (covers the previously broken indefinite case).
Refs #1487. Other symptoms listed in the issue (`unstable_cache`, fetch
cache directives, force-static, force-no-store, on-demand revalidate) are
out of scope here and tracked separately.
* test(app-page-response): update Infinity revalidate assertions
Production + revalidateSeconds: Infinity now writes to the ISR cache
(cacheState: "MISS", shouldWriteToCache: true). Update the existing
assertion to match, and add a dev-mode case asserting Infinity stays
as a no-write STATIC response in development.
* fix(pages-router): invoke Document.getInitialProps so docProps reach SSR (#1361)
`pages/_document.tsx` files that override `static async getInitialProps`
to inject extra props were rendered with an empty `this.props`, because
both the dev-server and the production pages response builder created
the Document element with `React.createElement(DocumentComponent)` and
never called the hook.
The Next.js async-modules e2e fixture
(`test/e2e/async-modules/pages/_document.jsx`) uses exactly that pattern
to surface a `docValue` from `await Document.getInitialProps(ctx)` plus
a top-level `await` constant. PR #1381 (issue #1361) fixed the class
construction crash, but the deploy-suite continued to fail
"csr async page modules" because `<div id="doc-value">` rendered empty.
This change adds a small `loadUserDocumentInitialProps` helper used by
both the Pages Router dev-server (`streamPageToResponse` shell and the
custom-error-page shell) and the production response builder
(`buildPagesShellHtml`). It invokes the override (if any) and spreads
the resolved props on the Document element, mirroring Next.js's
`render.tsx` `<Document {...htmlProps} {...docProps} />` call. The
helper short-circuits when the user did not override the base shim, so
the existing fast path keeps the same number of awaits.
Reference: vercel/next.js packages/next/src/server/render.tsx
(`loadDocumentInitialProps`, `documentElement`).
Tests:
- Adds a new pages-router production e2e case that builds a
`_document.tsx` with `static async getInitialProps` + top-level
`await`, plus a custom `404.tsx` that uses top-level `await`, and
asserts the resolved values reach the rendered HTML.
- Unit-tests `loadUserDocumentInitialProps` directly for the override,
no-override, and throwing-override cases.
Refs #1361
* fix(pages-router): address bonk review on Document.getInitialProps helper
Two changes from review feedback on PR #1633:
1. Cache the base getInitialProps reference at module level. The previous
helper did `await import("vinext/shims/document")` on every request to
compare identity — unnecessary per-request work and an extra await on
the fast path where the user has no override. Switched to a static
import + module-scoped constant so the identity check is a synchronous
reference compare. No-override callers now resolve with one less await.
2. Let user `getInitialProps` errors propagate. Next.js's `loadGetInitialProps`
does not catch — a throw surfaces as a 500 to the caller. The previous
version logged-and-swallowed the error and returned null, which
silently erased docProps on every failing render and made user bugs
harder to find. vinext now matches Next.js's contract.
Updated the corresponding unit test to assert the throw propagates rather
than that the helper resolves to null.
Refs #1361, #1633
* fix(pages-router): mark app routes as detected on prefetch (#1526)
In a hybrid Pages + App Router app, when the Pages Router prefetches a
`<Link href>` whose target is actually an App Router route, Next.js marks
the route on the Pages Router singleton with
`router.components[urlPathname] = { __appRouter: true }` (driven by the
`_bfl` bloom filter at packages/next/src/shared/lib/router/router.ts:2525).
The Next.js deploy test `test/e2e/app-dir/app/index.test.ts` ("should
successfully detect app route during prefetch") asserts this via
`window.next.router.components["/dashboard"]`.
Vinext previously did not expose `components` and did not record App Router
prefetch targets, so the assertion never resolved.
This commit:
- adds a shared `components` map (via `Symbol.for` for module-split safety)
on the Pages Router singleton, mirrored onto `window.next.router`,
- threads the App Router prefetch manifest into the Pages Router client
entry so the same matcher Link uses for App Router auto-prefetch can run
in Pages-only-entry pages,
- marks the target on `components` with `{ __appRouter: true }` from both
`Router.prefetch` and `<Link>` Pages-mode prefetch when the target
matches the App Router manifest.
* fix(app-route-detection): drop unused exports flagged by knip
Both `matchesAppRoute` and `PagesRouterComponentsMap` are only used
inside this module — knip rightly flagged them as unused exports.
Internalize both.
When a deep page called `forbidden()`/`unauthorized()`/`notFound()` and the
intermediate layout segments had no matching boundary file, vinext's
page-error fast path wrapped the resolved root boundary in *all* of the
route's layouts. That left the intermediate layout's chrome ("Dynamic with
Layout") rendered next to the boundary fallback, diverging from Next.js
where the nearest ancestor boundary owns the entire fallback subtree.
`renderPageSpecialError` now resolves the deepest layout-level boundary
via `resolveAppPageParentHttpAccessBoundary` and slices the layouts to
`[0..boundaryLayoutIndex]`, so layouts beneath the boundary owner stop
rendering. When the route-level boundary file lives next to the page
(not aligned to a layout), all layouts are kept as before.
Ported the Next.js regression cases from
`test/e2e/app-dir/forbidden/basic/forbidden-basic.test.ts` and
`test/e2e/app-dir/unauthorized/basic/unauthorized-basic.test.ts`.
* fix(app-router): honor experimental.staleTimes in client prefetch cache (#1490)
The App Router's client-side prefetch cache previously used a hard-coded
30s TTL and ignored `experimental.staleTimes` from next.config. As a
result, users could not extend (or shorten) how long prefetched route
segments were considered fresh, breaking parity with Next.js'
`test/e2e/app-dir/app-client-cache/client-cache.experimental.test.ts`.
Surface `experimental.staleTimes.{dynamic,static}` through
`ResolvedNextConfig` and inject it into the client bundle as
`process.env.__NEXT_CLIENT_ROUTER_{DYNAMIC,STATIC}_STALETIME` (matching
the Next.js variable names plumbed by `build/define-env.ts`). The
prefetch cache TTL in `shims/navigation.ts` now reads the static value
at module load time, converting seconds to ms.
Defaults mirror Next.js (`dynamic: 0`, `static: 300`). When the env var
is absent — primarily in unit tests that import the module outside the
plugin's `define` pipeline — we fall back to vinext's historical 30s
default rather than the Next.js 300s so existing tests keep passing.
Refs: .nextjs-ref/packages/next/src/client/components/router-reducer/reducers/navigate-reducer.ts
Refs: .nextjs-ref/packages/next/src/build/define-env.ts
* review: address bot feedback on staleTimes PR
- Remove invokeLoaderSideEffects scope creep (belongs to #1500 / PR #1657)
- Reject negative staleTimes at resolution time alongside Number.isFinite,
matching the seconds < 0 guard in resolvePrefetchCacheTtl
- Drop unused __NEXT_CLIENT_ROUTER_DYNAMIC_STALETIME define; vinext does
not yet distinguish prefetch kinds, so the value was never consumed
Some Next.js webpack loaders mutate `process.env.X = ...` at compile
time, expecting the value to be visible to other modules during the
same build. vinext doesn't run the webpack loader pipeline, so those
env mutations never happened and downstream code (defines,
`NEXT_PUBLIC_*`, server-side reads) saw `undefined`.
Walk the rules collected from the user's `webpack(config)` function
and invoke each referenced loader once with a dummy source. Loaders
that only mutate `process.env` get a chance to land their changes in
the shared Node process. Failures are swallowed since vinext doesn't
use the loader's transform output. Well-known framework loaders
(next-babel-loader, @next/mdx, next/dist/build/webpack/*) are skipped
to avoid pulling in webpack-runtime-dependent code at probe time.
In Next.js, the `@children` directory is special: it provides the
layout's `children` prop rather than acting as a parallel slot.
`app/foo/@children/page.tsx` should therefore register a real page
route at `/foo` and take priority over a sibling `[...catchAll]`
catch-all. Previously vinext excluded all `@`-prefixed directories
from the page scan, so `@children/page.tsx` was hidden and `/` (or
`/nested`) was either served by the catch-all or failed to resolve
when no `default.tsx` existed.
Three small changes restore Next.js parity:
- Let `@children` directories through the page-scan exclusion so the
page file at `@children/page.tsx` registers as a route.
- Strip a trailing `@children` segment in `fileToAppRoute` so the
route is anchored at the parent directory — sibling `@slot`
directories remain owned (not inherited) and layout/boundary
discovery is sourced from the parent.
- Skip `@children` in `discoverParallelSlots` and
`hasParallelSlotDirectory` so it never appears in
`parallelSlots` (matching Next.js' types-plugin behaviour).
Ported from Next.js: test/e2e/app-dir/parallel-routes-catchall-children-slot/
https://github.com/vercel/next.js/blob/canary/test/e2e/app-dir/parallel-routes-catchall-children-slot/parallel-routes-catchall-children-slot.test.ts
References Next.js' `normalizeAppPath` and `normalize-catchall-routes`
which both treat `@children` as a non-matchable slot:
- packages/next/src/shared/lib/router/utils/app-paths.ts
- packages/next/src/build/normalize-catchall-routes.ts
- packages/next/src/build/webpack/plugins/next-types-plugin/index.ts
Fixes#1535.
Multiple `cookies().set(name, ...)` calls on the same name inside a server
action emitted multiple Set-Cookie response headers, diverging from
Next.js's `MutableRequestCookiesAdapter`, whose underlying `ResponseCookies`
Map collapses repeated sets to the final value per name.
Apply `dedupePendingCookies` at every cookie-emitting action exit (form
action redirects, fetch action redirects, fetch action responses) so the
last write per name wins and insertion order is preserved.
Reference: packages/next/src/server/web/spec-extension/adapters/request-cookies.ts
Refs #1481.
Next.js's `metadata.icons.other` accepts either a single
`IconDescriptor` or an array of them, but `MetadataHead` iterated
it directly and threw `TypeError: metadata.icons.other is not iterable`
when given a single object. That crash bubbled up into the page
render so no `<link>` tags (favicon, shortcut, apple, custom) reached
the head at all for any page declaring `icons.other` as an object.
Normalize `metadata.icons.other` to an array before iterating, widen
its type to `OtherIconDescriptor | OtherIconDescriptor[]`, and also
forward the optional `type` attribute so descriptors like
`{ rel: "mask-icon", url, type: "image/svg+xml" }` round-trip
correctly. Ported coverage from
`test/e2e/app-dir/metadata-icons/metadata-icons.test.ts`.
Refs cloudflare/vinext#1492
Calling `await draftMode()` and reading `.isEnabled` inside a `"use cache"`
or `unstable_cache()` callback now works the same as Next.js: the
non-mutating reads succeed and reflect the `__prerender_bypass` cookie,
while only the side-effecting `enable()` / `disable()` calls throw when
invoked inside a cache scope.
Previously vinext threw eagerly on `draftMode()` itself, which caused
fixtures such as `app-static`'s `unstable-cache/dynamic` page (which
reads `(await draftMode()).isEnabled` inside the cached function) to
surface as empty/undefined values in the Next.js deploy suite.
Ported from `.nextjs-ref/packages/next/src/server/request/draft-mode.ts`
(`getDraftModeProviderForCacheScope` + `trackDynamicDraftMode`).
When a progressive (no-JS) server action POST runs without redirecting, the
pending `cookies().set(...)` / `draftMode().enable()` mutations made during
the action were dropped on the floor — the form-state result returned from
`handleProgressiveServerActionRequest` never read them out of the
request-scoped headers context, and the subsequent page rerender never
flushed them onto the response.
Mirror Next.js' `res.setHeader('set-cookie', ...)` flush in
`action-handler.ts` / `app-render.tsx`: capture pending cookies, the draft
cookie, and the resolved revalidation kind at the end of the non-redirect
action path, expose them on the form-state result, then append them to the
rerender response (and the `x-action-revalidated` marker) in
`app-rsc-handler`. Falls back to rebuilding the response when its headers are
immutable so cookies still ride a `redirect()` issued during the rerender.
Fixes#1483.
When getServerSideProps (or any other render-time code) threw in the
production server entry, vinext collapsed the response into a plain
"Internal Server Error" text body. Next.js instead renders the user's
custom pages/500.tsx (with pages/_error.tsx as a fallback). Match that
behaviour so frameworks that rely on custom error pages — and the
Next.js getserversideprops deploy suite — see the expected output.
The catch block in `_renderPage` now re-renders through the same entry
using `pages/500.tsx` (or the `_error` route) with status 500. A new
`__isInternalErrorRender` guard prevents infinite recursion if the error
page itself throws; data (`/_next/data/...`) requests still short-circuit
to the plain text body since they can't return HTML.
Mirrors Next.js base-server.ts `renderToResponseImpl` 500 fallback. The
dev server already renders custom 500/error pages via `renderErrorPage()`
— this aligns prod with that behaviour and adds explicit regression
coverage for both paths via a new gssp-throw fixture.
Refs #1458
User code such as `new Worker(new URL('./w.ts', import.meta.url))` reads
`process.env.NEXT_DEPLOYMENT_ID` from inside the worker scope, but vinext
only defined the internal `__VINEXT_DEPLOYMENT_ID` mirror — leaving the
public Next.js identifier as `undefined` in every browser-side bundle.
Mirror Next.js' webpack DefinePlugin behavior (see
packages/next/src/build/define-env.ts) and statically inline the value
into the global Vite `define`. The same map is applied to client, SSR,
RSC and Vite worker bundles, so workers transparently see the deployment
id without needing a globalThis bridge (which can't be shared across
the main-thread / worker boundary anyway).
When no deploymentId is configured, inline `false` — the same fallback
Next.js uses, so feature checks like `if (process.env.NEXT_DEPLOYMENT_ID)`
remain dead-code eliminated.
* feat(app-router): support inline CSS parity
App Router production builds ignored Next.js experimental.inlineCss, so HTML responses kept stylesheet links, next/font CSS lived in a second style tag, and Next-style RSC requests with RSC: 1 plus _rsc could return HTML.
The missing invariant was that inlineCss changes the production CSS delivery boundary: non-RSC HTML gets inlined style resources, RSC payloads keep CSS bodies out, and client navigations must not reintroduce duplicate stylesheet resources for CSS already present inline.
Resolve the config flag into the generated RSC entry, collect emitted CSS assets into an inline manifest for Node and Workers production, rewrite matching React stylesheet links into hoistable style tags, merge next/font CSS into the first inline style with a fallback path, and recognize Next-style RSC requests.
Regression coverage now ports the upstream app-inline-css behavior at production-browser level and adds focused tests for request normalization, stream rewriting, font merging, and fallback emission.
* feat(app-router): preserve inline CSS import ordering
Inline CSS font merging could prepend generated font rules before a stylesheet import. CSS imports must stay at the beginning of their stylesheet, so that ordering caused imported styles to be ignored when experimental.inlineCss and local font CSS were combined.
Keep import-sensitive stylesheet preambles untouched and let the existing font fallback style carry the font rules instead. Add stream-helper coverage for the import case.
* feat(app-router): harden inline CSS review edges
Inline CSS rewriting only saw complete link tags in a single decoded chunk and treated rel as an exact value. That left valid stylesheet links un-inlined when rel had multiple tokens or when streaming split the tag across chunks.
The production manifest injection also assumed the RSC worker bundle was always at dist/server/index.js, so custom rscOutDir builds missed the inline CSS manifest.
Buffer incomplete link tags across stream flushes, match stylesheet as a rel token, and inject the manifest into the configured RSC output entry. Add regressions for the streaming and custom-output cases.
* feat(app-router): match inline CSS cleanup semantics
Client navigation cleanup only pruned links whose rel was exactly stylesheet and whose precedence marker used data-precedence. That diverged from the server inline CSS rewrite, so tokenized rel values or legacy precedence links could survive after navigation as duplicate stylesheet resources.
The fix moves the cleanup into a testable helper, reuses shared HTML token-list matching for server and browser paths, accepts both precedence marker forms, and only buffers split link tags when an inline CSS manifest is present.
Regression coverage now covers browser cleanup and non-inlineCSS streaming chunk granularity.
* feat(app-router): harden inline CSS HTML rewriting
Inline CSS rewriting could prepend SSR font CSS ahead of namespace-bearing stylesheets and could treat stylesheet-like text inside script bodies as real link tags. That violates CSS ordering constraints and corrupts streamed script text when experimental.inlineCss is enabled.
The stream rewrite now treats @namespace as an unsafe preamble, skips link replacement inside raw-text and comment regions, and buffers incomplete rewrite boundaries across flushes. Regression coverage pins namespace fallback, complete script text, split script text, and unterminated script text.
* test(e2e): specify junction type for fs.symlink to support Windows
* refactor(app-router): drop write-only __PAGE__ wire marker
Every outgoing App Router payload carried `__PAGE__: true` in its wire
metadata, but nothing in the runtime ever read it. Its only consumer was
an inline-css E2E assertion checking that a dynamic navigation returned an
RSC payload rather than HTML, so the marker added permanent per-response
wire overhead with no behavioural effect.
The `__route` key is already present on every payload and proves the same
thing: the response carries page metadata. Remove the marker key, its type
field, and its re-export, and point the unit and E2E assertions at
`__route` instead.
* perf(app-router): skip inline-css manifest scan on the streaming hot path
The tick-buffered SSR transform recomputed `Object.keys(manifest).length`
on every flush through `rewriteInlineCssStylesheetLinks`, even when inline
CSS was disabled and the manifest empty. Streaming flushes are a hot path,
so this ran per chunk of every response for no benefit.
Compute the manifest-present flag once at transform creation and reuse it
to gate both the split-link boundary buffering and the link rewrite, so
non-inline-css responses skip the rewrite entirely. Also document the
shared-lastIndex constraint on the module-level rewrite regexes and the
startup/build-time population contract for `__VINEXT_INLINE_CSS__`.
* fix(app-router): forward SSR script nonce to inline-css <style> tags
Sites running `Content-Security-Policy: style-src 'nonce-…'` saw the
inlined `<style>` blocks blocked at parse time and rendered unstyled
when `experimental.inlineCss` was enabled. The `<link rel="stylesheet">`
tags the feature replaces aren't subject to inline-style CSP, but the
new inline blocks are — and React Fizz typically doesn't put a nonce on
the `<link>`, so the rewrite path had no nonce to carry over.
Thread the SSR-time `scriptNonce` through `createTickBufferedTransform`
into `rewriteInlineCssStylesheetLinks`, and prefer the link's own nonce
when present (otherwise fall back to the SSR nonce). Add unit coverage
for the SSR-only, link-only, and missing-nonce cases.
Also replace `html.toLowerCase().lastIndexOf("<link")` in
`splitTrailingIncompleteLinkTag` with a forward `g+i` regex scan so the
streaming hot path no longer allocates a lowercased copy of every flush
(can be tens of KB on large responses).
* chore(check): register experimental.inlineCss as supported
So `vp check` advertises App Router CSS inlining alongside the other
experimental flags. Notes that next/font CSS is folded into the first
inline `<style>` block.
---------
Co-authored-by: James <james@eli.cx>
* fix(otel): inject experimental.clientTraceMetadata into SSR head (#1494)
When `experimental.clientTraceMetadata` is configured in next.config, read
the active OpenTelemetry context via the registered propagator and emit
`<meta name="..." content="...">` tags in the SSR HTML head for each
allow-listed key. Both App Router and Pages Router are covered (dev and
prod servers). `@opentelemetry/api` is resolved as an optional peer at
runtime, so apps without OTel get a zero-cost no-op.
Mirrors Next.js: packages/next/src/server/lib/trace/utils.ts and
packages/next/src/server/app-render/make-get-server-inserted-html.tsx.
* fix(otel): drop unused getOpenTelemetryTraceData export
knip flagged the helper as unused — it is only consumed internally by
`getClientTraceMetadataHTML`. Keep it module-private.
* fix(otel): normalize clientTraceMetadata allow-list to undefined-only
Pick one convention for the optional allow-list across the App Router
pipeline (was mixing `string[] | null` and `string[] | undefined`).
Drops the redundant `?? null` / `?? undefined` coercions and aligns
every server-side type with `ResolvedNextConfig.clientTraceMetadata`,
which is `string[] | undefined`.
Also adds a resolveNextConfig test asserting that an array passed via
experimental.clientTraceMetadata is preserved verbatim, non-string
entries are filtered, and unset / non-array values resolve to
undefined.
When `app/global-not-found.tsx` is defined, route-miss 404s render that
module standalone (it ships its own `<html>`/`<body>` and replaces the
root layout). Previously the entry registered global-not-found.tsx as a
static `import * as`, which co-located its CSS with the root layout's CSS
in a single chunk. Lightningcss then dropped overlapping declarations
between the two stylesheets as dead code, so any rule global-not-found
defined that the layout also defined was silently removed — breaking the
CSS cascade for 404s.
Switching the entry to `() => import("…/global-not-found.tsx")` puts the
module in its own JS chunk and lets the SSR pipeline (and `Resources`
metadata) treat its CSS independently of the rest of the app. The
fallback renderer now accepts a `loadGlobalNotFoundModule` loader (cached
per worker) instead of an eagerly-imported module.
Also adds a regression test asserting the SSR markup for `/does-not-exist`
links only global-not-found's stylesheet — never the root layout's — so
the cascade can never resolve to the wrong color.
Ported from Next.js: test/e2e/app-dir/initial-css-order/initial-css-order.test.ts
`setRootParams` was only called after the post-action route match, so
server actions, progressive (form) actions, and route handlers all ran
before the unified request context's `rootParams` slice was populated.
User code calling `unstable_rootParams()` from those contexts therefore
saw `undefined` instead of the matched root layout's params.
Seed `setRootParams` from a pre-action route match against the current
cleanPathname so that:
- route handlers observe rootParams during dispatch
- server actions observe rootParams while the action runs and during
the page rerender that follows a successful action
- `"use cache"` functions invoked from any of those contexts read
rootParams from the unified request context
The legacy post-rewrite `setRootParams` call is preserved so the value
is refreshed if `afterFiles`/`fallback` rewrites land on a different
route (and consequently a different set of root param names).
When notFound() or redirect() is called from inside a Suspense boundary
the error surfaces after the shell has already streamed, so the not-found
/ redirect intent is communicated to the client via inline <meta> tags
injected into the head section of the stream.
vinext was emitting these as `<meta name="robots" content="noindex" />`
(with a space before the self-closing slash), but Next.js serializes them
via React's HTML renderer, which produces `<meta ... content="..."/>`
without the space. The Next.js navigation tests assert on that exact
substring, so this mismatch caused ~5 deploy-suite failures.
Drop the extra space so the streamed meta tags match Next.js byte-for-byte,
and add ported regression tests against the suspense fixtures.
Ref: packages/next/src/server/app-render/make-get-server-inserted-html.tsx
Ref: test/e2e/app-dir/navigation/navigation.test.ts (SEO describe block)
When the user configured `pageExtensions` with values beyond Vite's
defaults (e.g. `["platform.tsx", "tsx", "mdx"]`), extensionless imports
of files with those extensions failed to resolve and the build crashed
with `Custom deploy script failed: undefined (1)`.
Mirror Next.js / Turbopack `resolveExtensions` semantics: prepend the
configured `pageExtensions` (each prefixed with `.`) to Vite's default
extension list, preserving the user's priority so e.g. `.web.tsx`
resolves before `.tsx`.
Ported from Next.js: test/e2e/app-dir/resolve-extensions/
Refs: cloudflare/vinext#1502
* feat(config): implement compiler.define and compiler.defineServer (#1496)
Forward `compiler.define` to Vite's top-level `define` (applies to both
client and server bundles) and `compiler.defineServer` to non-client
environments only via a `configEnvironment` hook, matching Next.js
Webpack `DefinePlugin` semantics. Values are JSON-stringified at config
resolution time so they slot directly into Vite's substitution format.
Refs Next.js: packages/next/src/build/define-env.ts.
Fixes#1496
* fix(config): reject compiler.define keys that collide with built-ins
Mirrors Next.js (`packages/next/src/build/define-env.ts`) — throw when a
user-provided `compiler.define` or `compiler.defineServer` key would
silently overwrite an internal define (e.g. `process.env.NODE_ENV`,
`__NEXT_*`, `__VINEXT_*`) or when `define` and `defineServer` define the
same key. Without this, a misconfigured project would produce subtly
wrong output instead of failing fast.
Addresses /bigbonk review on #1638.
When `getStaticProps` or `getServerSideProps` returned props containing
non-JSON-serializable values (e.g. `Date`, `Map`, class instances), vinext
silently rendered an empty page instead of surfacing an error. This ports
Next.js's `isSerializableProps` check from `packages/next/src/lib/is-serializable-props.ts`
and invokes it from `pages-page-data.ts` and `dev-server.ts` after the
redirect/notFound short-circuits, mirroring `render.tsx` (~lines 982 and
1200). The thrown `SerializableError` is caught by the existing per-request
error boundary, which returns a 500 with a Next.js-style message naming the
offending key.
Calling router.push() and router.refresh() in the same transition could leave vinext on the current page instead of committing the pushed route. That diverged from Next.js and broke the default autoscroll target for the pushed page.
The refresh path dispatched a current-route RSC refresh before the nested push transition could finish scheduling, so the refresh superseded the intended navigation.
Track App Router push/replace scheduling for the current task, keep refresh cache invalidation, and skip only the overtaking current-route refresh. Add Next parity coverage for refresh, server-action refresh, focus targets, fragments, hoisted children, and metadata routes.
Match Next.js semantics: `updateTag` from `next/cache` must throw when
called outside a Server Action context (e.g. in a Route Handler or
during render), and only the in-action invariant invokes the cache
tag invalidation.
Detect the headers access phase ("action") via the existing shim and
throw the canonical error message otherwise. Existing in-action
behavior (immediate tag expiry via the active cache handler) is
preserved.
* fix(pages-router): emit page scripts with defer in <head> by default
Next.js' Pages Router emits page scripts with the `defer` attribute in
`<head>` when `experimental.disableOptimizedLoading` is false (the
default). vinext emits `<script type="module">` (which already defers
implicitly), but upstream tests assert the literal `defer` attribute
and were failing against the deploy suite.
Add `defer` to module scripts emitted by `collectAssetTags` when
`experimental.disableOptimizedLoading` is not enabled. Surface the
flag in `ResolvedNextConfig` so prod-server respects an explicit
opt-out. Browser behaviour is unchanged (module scripts already
defer), but parity tests now pass.
Fixes#1519.
* test(e2e): update hydration regex to allow defer attribute
The script tag regex in `tests/e2e/cloudflare-pages-router/hydration.spec.ts`
required `type="module"` to be immediately followed by `src="…"`, but the
optimized-loading fix inserts a `defer` attribute between them. Relax the
regex to allow any whitespace-separated attributes between `type="module"`
and `src` so future attribute additions don't break it either.
Nathan Nguyen