Tags: cloudflare/vinext
Tags
fix: Pages prod config headers and redirects after middleware rewrites ( #448) * Fix headers matching original path * Review redirect ordering parity * Fix config redirects order * Fix dev middleware parity * Fix dev middleware request parity * address review: worker header/fallback parity, early-return in attachRouteHandlerMiddlewareContext, cache node request headers, add dev redirect test * address second-round bonk comments: sanitizeDestination in worker redirect, nodeRequestHeaders comment, app-rsc-entry guard comment, E2E redirect test, updated snapshots --------- Co-authored-by: James <james@eli.cx>
feat: AsyncLocalStorage for ExecutionContext (ctx) propagation (#410) Adds request-context.ts shim with runWithExecutionContext() and getRequestExecutionContext() so Cloudflare Workers ctx is accessible anywhere in the call stack without manual threading. - New shims/request-context.ts with ALS keyed on Symbol.for('vinext.requestContext.als') - app-router-entry.ts wraps each request in runWithExecutionContext(ctx, ...) - app-rsc-entry.ts generated code imports the helpers for downstream use - deploy.ts generated worker entry forwards ctx in fetch(request, env, ctx) - kv-cache-handler.ts uses getRequestExecutionContext() ?? this.ctx - 8 new tests in tests/request-context.test.ts
feat(next-intl): auto-detect config without createNextIntlPlugin (#366) * fix: resolve NEXT_DATA type conflict with next package types next/dist/client/index.d.ts declares Window.__NEXT_DATA__ as NEXT_DATA, which conflicts with our inline type in global.d.ts. The vinext-specific extensions (__vinext, __pageModule, __appModule) aren't in NEXT_DATA, causing TS2339 errors. Extract vinext extensions into a VinextNextData interface and cast at the two usage sites (client/entry.ts, shims/link.tsx) instead of re-declaring __NEXT_DATA__ with a conflicting type. * feat(next-intl): auto-detect next-intl config without createNextIntlPlugin next-intl's createNextIntlPlugin() crashes in vinext because it calls require('next/package.json') to check the Next.js version, and next isn't installed. Instead, vinext now detects next-intl in project dependencies and registers the next-intl/config alias automatically. Detection probes i18n/request.{ts,tsx,js,jsx} then src/i18n/request.{ts,tsx,js,jsx}, matching next-intl's own discovery order. Explicit aliases from webpack/turbopack config take precedence. Also adds a targeted warning when config loading fails due to next-intl/plugin, telling users the wrapper is unnecessary. Closes #202 * fix: address review feedback - Update check.ts: next-intl status "partial" → "supported" - Extend VinextNextData from NEXT_DATA in shims/internal/utils.ts instead of duplicating fields - Add JSDoc note about monorepo resolution walk-up behavior
Escape closing tags in inline script/style SSR output (#284) The HTML parser treats </script> (and </style>) as the end of the containing element regardless of JavaScript/CSS string context. When dangerouslySetInnerHTML content contained these sequences, the SSR output could produce malformed HTML where the tag boundary was broken. Add escapeInlineContent() that replaces </script and </style with <\/script and <\/style (case-insensitive). Apply it in: - next/script: beforeInteractive SSR path - next/head: reactElementToHTML for script and style tags Includes 14 tests covering the escaping helper, Script component SSR, and Head component SSR.
fix: wire up RouterContext.Provider in Pages Router (#239) (#249) Add wrapWithRouterContext() function to the next/router shim that wraps any React element in a <RouterContext.Provider>. This is the root-cause fix: it builds the router value object directly from the SSR context (server) or window.location + Router singleton (client) — no hooks, no duplicate state, no extra component. This provides a single source of truth for the router context value, matching how Next.js provides RouterContext at the framework level. Wrapping sites: - dev-server.ts: main render, ISR re-render, error page render - index.ts virtual module: production renderPage and ISR re-render - Hydration script: client-side hydration entry - navigateClient: client-side navigation re-renders Tests: - useRouter returns null without provider (default/App Router) - useRouter returns full router when wrapWithRouterContext wraps tree - useRouter reflects SSR context (pathname, query, asPath) - wrapWithRouterContext is exported from next/router Closes #239
fix: new routes fail on running dev server (#235) * Skip deploy previews for fork PRs that lack Cloudflare secrets Fork PRs don't have access to repository secrets (CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID), so deploy/smoke-test/comment steps always fail. Add a fork detection condition to skip these steps gracefully. The build steps still run, so example builds are still validated for fork PRs. * fix: invalidate virtual RSC entry when app routes are added or removed The App Router route table is baked into the virtual RSC entry module at generation time. When a new route file is added (or removed) while the dev server is running, invalidateAppRouteCache() cleared the route scanner cache but the virtual module in Vite's module graph was never invalidated. This meant the load() hook was never re-called and the route table stayed stale, causing 404s for new routes until restart. Now the file watcher also invalidates the virtual RSC entry in Vite's module graph and sends a full-reload to the RSC environment, forcing route re-generation. Fixes #226
PreviousNext