vinext 0.2.0 → 1.0.0-beta.0

package/README.md

@@ -1,10 +1,34 @@
 # vinext
 
-The Next.js API surface, reimplemented on Vite.
+Run Next.js applications on Vite, with Cloudflare Workers as the primary deployment target.
 
 > **Read the announcement:** [How we rebuilt Next.js with AI in one week](https://blog.cloudflare.com/vinext/)
 
-> 🚧 **Experimental — under heavy development.** This project is an experiment in AI-driven software development. The vast majority of the code, tests, and documentation are written by AI, with humans steering throughout: setting architecture and priorities, making design decisions, reviewing changes, triaging complex problems, and shipping fixes. There may be bugs, rough edges, or things that don't work. Use at your own risk.
+> **Under active development.** vinext supports substantial Next.js applications today, but it is not yet a drop-in replacement for every application or production workload. Expect compatibility gaps, especially in newer App Router features, and evaluate it against your own application before adopting it.
+
+vinext reimplements the Next.js API surface on Vite rather than consuming `next build` output. It supports both the App Router and Pages Router, React Server Components, Server Actions, middleware, route handlers, ISR, static export, and the most commonly used `next/*` modules. Cloudflare Workers has the deepest integration; Node.js and other platforms are available with different levels of support.
+
+## Project status
+
+### What works today
+
+- **App Router and Pages Router** in development and production builds
+- **React Server Components, Server Actions, route handlers, and middleware**
+- **Static generation, ISR, `output: "export"`, and standalone Node.js output**
+- **Core Next.js APIs and modules**, including `next/link`, `next/image`, `next/navigation`, `next/headers`, `next/cache`, and the Metadata API
+- **Cloudflare Workers deployment** with bindings, cache adapters, and image optimization support
+- **Migration tooling** through `vinext check`, `vinext init`, and the vinext Agent Skill
+
+### Known gaps we're working on
+
+These are active compatibility areas, not permanent exclusions:
+
+- **Cache Components and Partial Prerendering:** `"use cache"` is partially implemented, but full `cacheComponents` behavior is still incomplete. Cache profiles, tags, partial shells, resume behavior, prefetching, and some dev/build cache semantics do not yet match Next.js in every case.
+- **Build-time image and font optimization:** images can be optimized at request time on Cloudflare, but vinext does not yet reproduce Next.js's complete build-time image pipeline. Google Fonts are loaded from the CDN, and local font CSS is injected at runtime rather than extracted during the build.
+- **Native modules in App Router development:** packages such as `sharp`, `resvg`, `satori`, `lightningcss`, and `@napi-rs/canvas` can fail in Vite's RSC development environment. Production builds support more of these cases than development mode.
+- **Platform-specific and advanced Next.js behavior:** `runtime` and `preferredRegion` route config are currently ignored, and some recently introduced or undocumented Next.js behavior may not yet be reproduced.
+
+Run `vinext check` against an existing application before migrating. If a gap is not listed here, check the [open issues](https://github.com/cloudflare/vinext/issues) or file a focused reproduction.
 
 ## Quick start
 
@@ -25,13 +49,15 @@ The skill handles compatibility checking, dependency installation, config genera
 ### Or do it manually
 
 ```bash
-npm install -D vinext vite @vitejs/plugin-react
+npm install vinext
+npm install -D vite @vitejs/plugin-react
 ```
 
 If you're using the App Router, also install:
 
 ```bash
-npm install -D @vitejs/plugin-rsc react-server-dom-webpack
+npm install react-server-dom-webpack
+npm install -D @vitejs/plugin-rsc
 ```
 
 Replace `next` with `vinext` in your scripts:
@@ -93,9 +119,15 @@ Environment variables: `PORT` (default `3000`), `HOST` (default `0.0.0.0`).
 
 ### Starting a new vinext project
 
-Run `npm create next-app@latest` to create a new Next.js project, and then follow these instructions to migrate it to vinext.
+Use `create-vinext-app` for new projects. It creates a TypeScript App Router project
+with Tailwind CSS and then runs the same vinext init setup used for existing apps:
+
+```bash
+pnpm create vinext-app@latest my-app
+```
 
-In the future, we will have a proper `npm create vinext` new project workflow.
+The generated project is Cloudflare Workers-ready by default. Pass
+`--platform=node` if you want the Node target instead.
 
 ### Migrating an existing Next.js project
 
@@ -108,7 +140,7 @@ npx vinext init
 This will:
 
 1. Run `vinext check` to scan for compatibility issues
-2. Install `vite`, `@vitejs/plugin-react`, and App Router-only deps (`@vitejs/plugin-rsc`, `react-server-dom-webpack`) as devDependencies
+2. Install vinext runtime packages as dependencies and Vite/plugin tooling as devDependencies
 3. Rename CJS config files (e.g. `postcss.config.js` -> `.cjs`) to avoid ESM conflicts
 4. Add `"type": "module"` to `package.json`
 5. Add `dev:vinext`, `build:vinext`, and `start:vinext` scripts to `package.json`
@@ -136,7 +168,7 @@ the compatibility report.
 
 Vite has become the default build tool for modern web frameworks — fast HMR, a clean plugin API, native ESM, and a growing ecosystem. With [`@vitejs/plugin-rsc`](https://github.com/vitejs/vite-plugin-react/tree/main/packages/plugin-rsc) adding React Server Components support, it's now possible to build a full RSC framework on Vite.
 
-vinext is an experiment: can we reimplement the Next.js API surface on Vite, so that existing Next.js applications can run on a completely different toolchain? The answer, so far, is mostly yes.
+vinext reimplements the Next.js API surface on Vite so existing Next.js applications can run on a different toolchain. The answer, so far, is that substantial applications can.
 
 vinext works everywhere. It natively supports Cloudflare Workers (with `npx @vinext/cloudflare deploy` or `vp exec vinext-cloudflare deploy`, bindings, KV caching), and can be deployed to Vercel, Netlify, AWS, Deno Deploy, and more via the [Nitro](https://v3.nitro.build/) Vite plugin. Native support for additional platforms is [planned](https://github.com/cloudflare/vinext/issues/80).
 
@@ -158,13 +190,13 @@ vinext works everywhere. It natively supports Cloudflare Workers (with `npx @vin
 vinext is a Vite plugin that reimplements the public Next.js API — routing, server rendering, `next/*` module imports, the CLI — so you can run Next.js applications on Vite instead of the Next.js compiler toolchain. It can be deployed anywhere: Cloudflare Workers is the first natively supported target, with other platforms available via Nitro. Native adapters for more platforms are [planned](https://github.com/cloudflare/vinext/issues/80).
 
 **Is this a fork of Next.js?**
-No. vinext is an alternative implementation of the Next.js API surface built on Vite. It does import some Next.js types and utilities, but the core is written from scratch. The goal is not to create a competing framework or add features beyond what Next.js offers — it's an experiment in how far AI-driven development and Vite's toolchain can go in replicating an existing, well-defined API surface.
+No. vinext is an alternative implementation of the Next.js API surface built on Vite. It does import some Next.js types and utilities, but the core is written from scratch. The goal is not to create a competing framework or add features beyond what Next.js offers; it is to provide the same well-defined API surface on Vite's toolchain.
 
 **How is this different from OpenNext?**
-[OpenNext](https://opennext.js.org/) adapts the _output_ of a standard `next build` to run on various platforms. Because it builds on Next.js's own output, it inherits broad API coverage and has been well-tested for much longer. vinext takes a different approach: it reimplements the Next.js APIs on Vite from scratch, which means faster builds and smaller bundles, but less coverage of the long tail of Next.js features. If you need a mature, well-tested way to run Next.js outside Vercel, OpenNext is the safer choice. If you're interested in experimenting with a lighter toolchain and don't need every Next.js API, vinext might be worth a look.
+[OpenNext](https://opennext.js.org/) adapts the _output_ of a standard `next build` to run on various platforms. Because it builds on Next.js's own output, it inherits broad API coverage and has been well-tested for much longer. vinext takes a different approach: it reimplements the Next.js APIs on Vite from scratch, which means faster builds and smaller bundles, but less coverage of the long tail of Next.js features. If you need a mature, well-tested way to run Next.js outside Vercel, OpenNext is the safer choice. If you want a lighter Vite-based toolchain and do not need every Next.js API, vinext may be a good fit.
 
 **Can I use this in production?**
-You can, with caution. This is experimental software with known bugs. It works well enough for demos and exploration, but it hasn't been battle-tested with real production traffic.
+You can, with caution. vinext has known compatibility gaps and has not yet been battle-tested across the full range of production Next.js workloads. Evaluate the features and deployment target your application relies on before adopting it.
 
 **Can I just self-host Next.js?**
 Yes. Next.js supports [self-hosting](https://nextjs.org/docs/app/building-your-application/deploying#self-hosting) on Node.js servers, Docker containers, and static exports. If you're happy with the Next.js toolchain and just want to run it somewhere other than Vercel, self-hosting is the simplest path.
@@ -176,7 +208,7 @@ The test suite has over 1,700 Vitest tests and 380 Playwright E2E tests. This in
 A mix of humans and AI agents. Humans review PRs before they merge, focused on behavior, structure, and long-term direction. We lean heavily on agent-driven code review to catch issues at PR time and across the codebase. The test suite is the primary quality gate. Outside contributions and deeper human code review are very welcome.
 
 **Why Vite?**
-Vite is an excellent build tool with a rich plugin ecosystem, first-class ESM support, and fast HMR. The [`@vitejs/plugin-rsc`](https://github.com/vitejs/vite-plugin-react/tree/main/packages/plugin-rsc) plugin adds React Server Components support with multi-environment builds. This project is an experiment to see how much of the Next.js developer experience can be replicated on top of Vite's infrastructure.
+Vite is an excellent build tool with a rich plugin ecosystem, first-class ESM support, and fast HMR. The [`@vitejs/plugin-rsc`](https://github.com/vitejs/vite-plugin-react/tree/main/packages/plugin-rsc) plugin adds React Server Components support with multi-environment builds. vinext builds the Next.js developer experience on top of that infrastructure.
 
 **Does this support the Pages Router, App Router, or both?**
 Both. File-system routing, SSR, client hydration, and deployment to Cloudflare Workers work for both routers.
@@ -240,7 +272,7 @@ Use `--env <name>` to target `wrangler.jsonc` `env.<name>`. `--preview` is short
 The init command also auto-detects and fixes common migration issues:
 
 - Adds `"type": "module"` to package.json if missing
-- Resolves tsconfig.json path aliases automatically (via `vite-tsconfig-paths`)
+- Resolves tsconfig.json path aliases automatically with Vite's native resolver
 - Detects MDX usage and configures `@mdx-js/rollup`
 - Renames CJS config files (postcss.config.js, etc.) to `.cjs` when needed
 - Detects native Node.js modules (sharp, resvg, satori, lightningcss, @napi-rs/canvas) and auto-stubs them for Workers. If you encounter others that need stubbing, PRs are welcome.
@@ -600,27 +632,16 @@ vinext({
 
 ## What's NOT supported (and won't be)
 
-These are intentional exclusions. For things that are missing today but on the roadmap, see [Known limitations](#known-limitations) below.
+These are intentional exclusions. For things that are missing today but on the roadmap, see [Known gaps we're working on](#known-gaps-were-working-on) above.
 
 - **Vercel-specific features** — `@vercel/og` edge runtime, Vercel Analytics integration, Vercel KV/Blob/Postgres bindings. Use platform equivalents.
 - **AMP** — Deprecated since Next.js 13. `useAmp()` returns `false`.
 - **`next export` (legacy)** — Use `output: 'export'` in config instead.
 - **Turbopack/webpack configuration** — This runs on Vite. Use Vite plugins instead of webpack loaders/plugins.
 - **`next/jest`** — Use Vitest.
-- **`create-next-app` scaffolding** — Not a goal.
+- **`create-next-app` scaffolding** — Use `create-vinext-app` for new vinext projects.
 - **Bug-for-bug parity with undocumented behavior** — If it's not in the Next.js docs, we probably don't replicate it.
 
-## Known limitations
-
-These are gaps we'd like to close — distinct from the [intentional exclusions](#whats-not-supported-and-wont-be) above.
-
-- **Image optimization doesn't happen at build time.** Remote images work via `@unpic/react` (auto-detects 28 CDN providers). Local images are routed through a `/_next/image` endpoint that can resize and transcode on Cloudflare Workers (via the Images binding) in production, but no build-time optimization or static resizing occurs.
-- **Google Fonts are loaded from the CDN, not self-hosted.** No `size-adjust` fallback font metrics. Local fonts work but `@font-face` CSS is injected at runtime, not extracted at build time.
-- **Route segment config** — `runtime` and `preferredRegion` are ignored (everything runs in the same environment).
-- **Node.js production server (`vinext start`)** works for testing but is less complete than Workers deployment. Cloudflare Workers is the primary target.
-- **Native Node modules (sharp, resvg, satori, lightningcss, @napi-rs/canvas)** crash Vite's RSC dev environment. Dynamic OG image/icon routes using these work in production builds but not in dev mode. These are auto-stubbed during `@vinext/cloudflare deploy`.
-- **`next.config.ts` `baseUrl` bare imports require Vite 8.** A `next.config.ts` that imports a bare specifier resolved through `tsconfig.json`'s `compilerOptions.baseUrl` (e.g. `import { bar } from "bar"` resolving to a local `bar.ts`) relies on Vite 8's native `resolve.tsconfigPaths` (Rolldown/oxc-resolver). On Vite 7 there is no native equivalent, so these imports are not resolved. `compilerOptions.paths` aliases (e.g. `@/foo`) work on both Vite 7 and 8. Note that if a bare import matches both a `baseUrl`-local file and an installed package of the same name, the installed package wins (vinext keeps packages externalized so CJS config plugins like `@next/mdx` keep working).
-
 ## Benchmarks
 
 > **Caveat:** Benchmarks are hard to get right and these are early results. Take them as directional, not definitive.
@@ -642,7 +663,7 @@ Benchmarks run on GitHub CI runners (2-core Ubuntu) on every merge to `main`. Se
 
 Analysis of the build output shows two main factors:
 
-1. **Tree-shaking**: Vite/Rollup produces a smaller React+ReactDOM bundle than Next.js/Turbopack. Rollup's more aggressive dead-code elimination accounts for roughly half the overall difference.
+1. **Tree-shaking**: Vite/Rolldown produces a smaller React+ReactDOM bundle than Next.js/Turbopack. Rolldown's more aggressive dead-code elimination accounts for roughly half the overall difference.
 2. **Framework overhead**: Next.js ships more client-side infrastructure (router, Turbopack runtime loader, prefetching, error handling) than vinext's lighter client runtime.
 
 Both frameworks ship the same app code and the same RSC client runtime (`react-server-dom-webpack`). The difference is in how much of React's internals survive tree-shaking and how much framework plumbing each tool adds.
@@ -769,11 +790,11 @@ Or add it to your `package.json` as a file dependency:
 }
 ```
 
-vinext has peer dependencies on `react ^19.2.6`, `react-dom ^19.2.6`, `react-server-dom-webpack ^19.2.6`, and `vite ^7.0.0 || ^8.0.0`. Then replace `next` with `vinext` in your scripts and run as normal.
+vinext has peer dependencies on `react ^19.2.6`, `react-dom ^19.2.6`, `react-server-dom-webpack ^19.2.6`, and `vite ^8.0.0`. Then replace `next` with `vinext` in your scripts and run as normal.
 
 ## Contributing
 
-This project is experimental and under active development. Issues and PRs are welcome.
+This project is under active development. Issues and PRs are welcome.
 
 ### CI
 

package/dist/build/client-build-config.d.ts

@@ -7,13 +7,6 @@ type ClientAssetFileNameInfo = {
   readonly originalFileName?: string;
   readonly originalFileNames?: readonly string[];
 };
-type RscFrameworkModuleInfo = {
-  importers: string[];
-  isEntry: boolean;
-};
-type RscFrameworkManualChunksMeta = {
-  getModuleInfo(id: string): RscFrameworkModuleInfo | null;
-};
 /**
  * Routes client assets into Next-compatible subtrees: `.css` sources go to
  * `<assetsDir>/css/`, everything else to `<assetsDir>/media/`. Returned as a
@@ -42,31 +35,15 @@ declare function createClientAssetFileNames(assetsDir: string): (assetInfo: Clie
  *   mobile devices.
  * - No major Vite-based framework (Remix, SvelteKit, Astro, TanStack)
  *   uses per-package splitting. Next.js only isolates packages >160KB.
- * - Rollup's graph-based splitting already handles the common case
+ * - The bundler's graph-based splitting already handles the common case
  *   well: shared dependencies between routes get their own chunks,
  *   and route-specific code stays in route chunks.
  */
 declare function createClientManualChunks(shimsDir: string, preserveRouteBoundaries?: boolean): (id: string) => string | undefined;
-/**
- * Rollup output config with manualChunks for client code-splitting.
- * Used by both CLI builds and multi-environment builds.
- *
- * experimentalMinChunkSize merges tiny shared chunks (< 10KB) back into
- * their importers. This reduces HTTP request count and improves gzip
- * compression efficiency — small files restart the compression dictionary,
- * adding ~5-15% wire overhead vs fewer larger chunks.
- */
 declare function createClientFileNameConfig(assetsDir: string): {
   entryFileNames: string;
   chunkFileNames: string;
 };
-declare function createClientOutputConfig(clientManualChunks: (id: string) => string | undefined, assetsDir: string): {
-  assetFileNames: (assetInfo: ClientAssetFileNameInfo) => string;
-  manualChunks: (id: string) => string | undefined;
-  experimentalMinChunkSize: number;
-  entryFileNames: string;
-  chunkFileNames: string;
-};
 declare function createClientCodeSplittingConfig(clientManualChunks: (id: string) => string | undefined): {
   minSize: number;
   groups: {
@@ -82,13 +59,12 @@ declare const RSC_FRAMEWORK_CHUNK_TEST: RegExp;
 declare function isRscFrameworkModule(id: string): boolean;
 /**
  * Output config that isolates React (and the RSC flight runtime) into a
- * dedicated "framework" chunk in the RSC server build. Returns the bundler-
- * appropriate shape: rolldown's `codeSplitting` for Vite 8+, Rollup's
- * `manualChunks` for Vite 7. See {@link RSC_FRAMEWORK_CHUNK_TEST} for the
- * motivation (issue #1549). Framework modules that are only reachable through
- * dynamic imports must stay out of the eager framework chunk (issue #2073).
+ * dedicated "framework" chunk in the RSC server build. See
+ * {@link RSC_FRAMEWORK_CHUNK_TEST} for the motivation (issue #1549). Framework
+ * modules that are only reachable through dynamic imports must stay out of the
+ * eager framework chunk (issue #2073).
  */
-declare function createRscFrameworkChunkOutputConfig(viteMajorVersion: number): {
+declare function createRscFrameworkChunkOutputConfig(): {
   codeSplitting: {
     groups: {
       name: string;
@@ -96,76 +72,21 @@ declare function createRscFrameworkChunkOutputConfig(viteMajorVersion: number):
       entriesAware: boolean;
     }[];
   };
-  manualChunks?: undefined;
-} | {
-  manualChunks(id: string, meta: RscFrameworkManualChunksMeta): string | undefined;
-  codeSplitting?: undefined;
-};
-/**
- * Rollup treeshake configuration for production client builds.
- *
- * Uses the 'recommended' preset as a safe base, then overrides
- * moduleSideEffects to strip unused re-exports from npm packages.
- *
- * The 'no-external' value for moduleSideEffects means:
- * - Local project modules: preserve side effects (CSS imports, polyfills)
- * - node_modules packages: treat as side-effect-free unless exports are used
- *
- * This is the single highest-impact optimization for large barrel-exporting
- * libraries like mermaid, @mui/material, lucide-react, etc. These libraries
- * re-export hundreds of sub-modules through barrel files. Without this,
- * Rollup preserves every sub-module even when only a few exports are consumed.
- *
- * Why 'no-external' instead of false (global side-effect-free)?
- * - User code may rely on import-time side effects (e.g., `import './global.css'`)
- * - 'no-external' is safe for app code while still enabling aggressive DCE for deps
- *
- * Why not the 'smallest' preset?
- * - 'smallest' also sets propertyReadSideEffects: false and
- *   tryCatchDeoptimization: false, which can break specific libraries
- *   that rely on property access side effects or try/catch for feature detection
- * - 'recommended' + 'no-external' gives most of the benefit with less risk
- *
- * @deprecated Use getClientTreeshakeConfigForVite(viteMajorVersion) instead
- * for Vite version compatibility. Kept for backward compatibility.
- */
-declare const clientTreeshakeConfig: {
-  preset: "recommended";
-  moduleSideEffects: "no-external";
 };
 /**
- * Returns treeshake configuration appropriate for the Vite version.
- *
- * Rollup (Vite 7) supports presets like "recommended" which set multiple
- * treeshake options at once. Rolldown (Vite 8+) doesn't support presets,
- * so we only return moduleSideEffects for Vite 8+.
- *
- * The Rollup "recommended" preset sets:
- * - annotations: true (Rolldown default is also true)
- * - manualPureFunctions: [] (Rolldown default is also [])
- * - propertyReadSideEffects: true (Rolldown equivalent is 'always', the default)
- * - unknownGlobalSideEffects: false (Rolldown default is true — this is a known acceptable
- *   divergence. Slightly less aggressive DCE on unknown globals, acceptable for client bundles)
- * - correctVarValueBeforeDeclaration and tryCatchDeoptimization (Rolldown handles these differently)
+ * Returns Rolldown treeshake configuration for production client builds.
  *
  * The key optimization is moduleSideEffects: "no-external", which is supported
- * by both bundlers and provides the DCE benefits for barrel-exporting libraries.
- * It treats node_modules as side-effect-free (enabling aggressive DCE) while
- * preserving side effects in local code.
+ * by Rolldown and provides the DCE benefits for barrel-exporting libraries. It
+ * treats node_modules as side-effect-free while preserving side effects in
+ * local code.
  */
-declare function getClientTreeshakeConfigForVite(viteMajorVersion: number): {
-  moduleSideEffects: "no-external";
-  preset?: undefined;
-} | {
-  preset: "recommended";
+declare function getClientTreeshakeConfig(): {
   moduleSideEffects: "no-external";
 };
 type VinextBuildConfig = NonNullable<UserConfig["build"]>;
 type VinextBuildBundlerOptions = NonNullable<VinextBuildConfig["rolldownOptions"]>;
-type VinextBuildConfigWithLegacy = VinextBuildConfig & {
-  rollupOptions?: VinextBuildBundlerOptions;
-};
 declare function getBuildBundlerOptions(build: UserConfig["build"] | undefined): VinextBuildBundlerOptions | undefined;
-declare function withBuildBundlerOptions(viteMajorVersion: number, bundlerOptions: VinextBuildBundlerOptions): Partial<VinextBuildConfigWithLegacy>;
+declare function withBuildBundlerOptions(bundlerOptions: VinextBuildBundlerOptions): Partial<VinextBuildConfig>;
 //#endregion
-export { RSC_FRAMEWORK_CHUNK_TEST, clientTreeshakeConfig, createClientAssetFileNames, createClientCodeSplittingConfig, createClientFileNameConfig, createClientManualChunks, createClientOutputConfig, createRscFrameworkChunkOutputConfig, getBuildBundlerOptions, getClientTreeshakeConfigForVite, isRscFrameworkModule, withBuildBundlerOptions };
+export { RSC_FRAMEWORK_CHUNK_TEST, createClientAssetFileNames, createClientCodeSplittingConfig, createClientFileNameConfig, createClientManualChunks, createRscFrameworkChunkOutputConfig, getBuildBundlerOptions, getClientTreeshakeConfig, isRscFrameworkModule, withBuildBundlerOptions };

package/dist/build/client-build-config.js

@@ -78,7 +78,7 @@ function getPackageName(id) {
 *   mobile devices.
 * - No major Vite-based framework (Remix, SvelteKit, Astro, TanStack)
 *   uses per-package splitting. Next.js only isolates packages >160KB.
-* - Rollup's graph-based splitting already handles the common case
+* - The bundler's graph-based splitting already handles the common case
 *   well: shared dependencies between routes get their own chunks,
 *   and route-specific code stays in route chunks.
 */
@@ -101,15 +101,6 @@ function createClientManualChunks(shimsDir, preserveRouteBoundaries = false) {
 		}
 	};
 }
-/**
-* Rollup output config with manualChunks for client code-splitting.
-* Used by both CLI builds and multi-environment builds.
-*
-* experimentalMinChunkSize merges tiny shared chunks (< 10KB) back into
-* their importers. This reduces HTTP request count and improves gzip
-* compression efficiency — small files restart the compression dictionary,
-* adding ~5-15% wire overhead vs fewer larger chunks.
-*/
 function createClientFileNameConfig(assetsDir) {
 	const chunksDir = `${assetsDir}/chunks`;
 	return {
@@ -117,14 +108,6 @@ function createClientFileNameConfig(assetsDir) {
 		chunkFileNames: `${chunksDir}/[name]-[hash].js`
 	};
 }
-function createClientOutputConfig(clientManualChunks, assetsDir) {
-	return {
-		...createClientFileNameConfig(assetsDir),
-		assetFileNames: createClientAssetFileNames(assetsDir),
-		manualChunks: clientManualChunks,
-		experimentalMinChunkSize: 1e4
-	};
-}
 function createClientCodeSplittingConfig(clientManualChunks) {
 	return {
 		minSize: 1e4,
@@ -174,97 +157,36 @@ function isRscFrameworkModule(id) {
 	const pkg = getPackageName(id);
 	return pkg !== null && FRAMEWORK_PACKAGES.includes(pkg);
 }
-function isStaticallyReachableFromEntry(id, meta, visited = /* @__PURE__ */ new Set()) {
-	if (visited.has(id)) return false;
-	visited.add(id);
-	const moduleInfo = meta.getModuleInfo(id);
-	if (!moduleInfo) return false;
-	if (moduleInfo.isEntry) return true;
-	return moduleInfo.importers.some((importer) => isStaticallyReachableFromEntry(importer, meta, visited));
-}
 /**
 * Output config that isolates React (and the RSC flight runtime) into a
-* dedicated "framework" chunk in the RSC server build. Returns the bundler-
-* appropriate shape: rolldown's `codeSplitting` for Vite 8+, Rollup's
-* `manualChunks` for Vite 7. See {@link RSC_FRAMEWORK_CHUNK_TEST} for the
-* motivation (issue #1549). Framework modules that are only reachable through
-* dynamic imports must stay out of the eager framework chunk (issue #2073).
+* dedicated "framework" chunk in the RSC server build. See
+* {@link RSC_FRAMEWORK_CHUNK_TEST} for the motivation (issue #1549). Framework
+* modules that are only reachable through dynamic imports must stay out of the
+* eager framework chunk (issue #2073).
 */
-function createRscFrameworkChunkOutputConfig(viteMajorVersion) {
-	if (viteMajorVersion >= 8) return { codeSplitting: { groups: [{
+function createRscFrameworkChunkOutputConfig() {
+	return { codeSplitting: { groups: [{
 		name: "framework",
 		test: RSC_FRAMEWORK_CHUNK_TEST,
 		entriesAware: true
 	}] } };
-	return { manualChunks(id, meta) {
-		return isRscFrameworkModule(id) && isStaticallyReachableFromEntry(id, meta) ? "framework" : void 0;
-	} };
 }
 /**
-* Rollup treeshake configuration for production client builds.
-*
-* Uses the 'recommended' preset as a safe base, then overrides
-* moduleSideEffects to strip unused re-exports from npm packages.
-*
-* The 'no-external' value for moduleSideEffects means:
-* - Local project modules: preserve side effects (CSS imports, polyfills)
-* - node_modules packages: treat as side-effect-free unless exports are used
-*
-* This is the single highest-impact optimization for large barrel-exporting
-* libraries like mermaid, @mui/material, lucide-react, etc. These libraries
-* re-export hundreds of sub-modules through barrel files. Without this,
-* Rollup preserves every sub-module even when only a few exports are consumed.
-*
-* Why 'no-external' instead of false (global side-effect-free)?
-* - User code may rely on import-time side effects (e.g., `import './global.css'`)
-* - 'no-external' is safe for app code while still enabling aggressive DCE for deps
-*
-* Why not the 'smallest' preset?
-* - 'smallest' also sets propertyReadSideEffects: false and
-*   tryCatchDeoptimization: false, which can break specific libraries
-*   that rely on property access side effects or try/catch for feature detection
-* - 'recommended' + 'no-external' gives most of the benefit with less risk
-*
-* @deprecated Use getClientTreeshakeConfigForVite(viteMajorVersion) instead
-* for Vite version compatibility. Kept for backward compatibility.
-*/
-const clientTreeshakeConfig = {
-	preset: "recommended",
-	moduleSideEffects: "no-external"
-};
-/**
-* Returns treeshake configuration appropriate for the Vite version.
-*
-* Rollup (Vite 7) supports presets like "recommended" which set multiple
-* treeshake options at once. Rolldown (Vite 8+) doesn't support presets,
-* so we only return moduleSideEffects for Vite 8+.
-*
-* The Rollup "recommended" preset sets:
-* - annotations: true (Rolldown default is also true)
-* - manualPureFunctions: [] (Rolldown default is also [])
-* - propertyReadSideEffects: true (Rolldown equivalent is 'always', the default)
-* - unknownGlobalSideEffects: false (Rolldown default is true — this is a known acceptable
-*   divergence. Slightly less aggressive DCE on unknown globals, acceptable for client bundles)
-* - correctVarValueBeforeDeclaration and tryCatchDeoptimization (Rolldown handles these differently)
+* Returns Rolldown treeshake configuration for production client builds.
 *
 * The key optimization is moduleSideEffects: "no-external", which is supported
-* by both bundlers and provides the DCE benefits for barrel-exporting libraries.
-* It treats node_modules as side-effect-free (enabling aggressive DCE) while
-* preserving side effects in local code.
+* by Rolldown and provides the DCE benefits for barrel-exporting libraries. It
+* treats node_modules as side-effect-free while preserving side effects in
+* local code.
 */
-function getClientTreeshakeConfigForVite(viteMajorVersion) {
-	if (viteMajorVersion >= 8) return { moduleSideEffects: "no-external" };
-	return {
-		preset: "recommended",
-		moduleSideEffects: "no-external"
-	};
+function getClientTreeshakeConfig() {
+	return { moduleSideEffects: "no-external" };
 }
 function getBuildBundlerOptions(build) {
-	const buildConfig = build;
-	return buildConfig?.rolldownOptions ?? buildConfig?.rollupOptions;
+	return build?.rolldownOptions;
 }
-function withBuildBundlerOptions(viteMajorVersion, bundlerOptions) {
-	return viteMajorVersion >= 8 ? { rolldownOptions: bundlerOptions } : { rollupOptions: bundlerOptions };
+function withBuildBundlerOptions(bundlerOptions) {
+	return { rolldownOptions: bundlerOptions };
 }
 //#endregion
-export { RSC_FRAMEWORK_CHUNK_TEST, clientTreeshakeConfig, createClientAssetFileNames, createClientCodeSplittingConfig, createClientFileNameConfig, createClientManualChunks, createClientOutputConfig, createRscFrameworkChunkOutputConfig, getBuildBundlerOptions, getClientTreeshakeConfigForVite, isRscFrameworkModule, withBuildBundlerOptions };
+export { RSC_FRAMEWORK_CHUNK_TEST, createClientAssetFileNames, createClientCodeSplittingConfig, createClientFileNameConfig, createClientManualChunks, createRscFrameworkChunkOutputConfig, getBuildBundlerOptions, getClientTreeshakeConfig, isRscFrameworkModule, withBuildBundlerOptions };

package/dist/build/css-url-assets.d.ts

@@ -13,6 +13,8 @@ type EmitRestoredCssUrlAsset = (asset: {
  * safe to run on every build-environment stylesheet, vendored CSS included.
  */
 declare function markCssUrlAssetReferences(code: string, id: string): string | null;
+/** Rebase relative asset URLs when Sass inlines a partial into an entry file. */
+declare function rebaseCssUrlAssetReferences(code: string, sourceDirectory: string, targetDirectory: string): string | null;
 /**
  * Mutates emitted CSS assets in place so byte-identical `url()` dependencies
  * keep their distinct Next-compatible filenames. Sibling files are produced via
@@ -26,4 +28,4 @@ declare function markCssUrlAssetReferences(code: string, id: string): string | n
  */
 declare function restoreDedupedCssAssetReferences(bundle: CssUrlAssetBundle, emitRestoredAsset: EmitRestoredCssUrlAsset): void;
 //#endregion
-export { markCssUrlAssetReferences, restoreDedupedCssAssetReferences };
+export { markCssUrlAssetReferences, rebaseCssUrlAssetReferences, restoreDedupedCssAssetReferences };

package/dist/build/css-url-assets.js

@@ -1,3 +1,4 @@
+import path from "node:path";
 //#region src/build/css-url-assets.ts
 /**
 * Next-parity for CSS `url()` asset dependencies.
@@ -128,6 +129,22 @@ function markCssUrlAssetReferences(code, id) {
 		});
 	});
 }
+/** Rebase relative asset URLs when Sass inlines a partial into an entry file. */
+function rebaseCssUrlAssetReferences(code, sourceDirectory, targetDirectory) {
+	return rewriteCssUrls(code, (rawUrl) => {
+		const parts = splitUrl(rawUrl.trim());
+		if (!isRelativeAssetUrl(parts.path)) return null;
+		const lower = parts.path.toLowerCase();
+		if (!CSS_ASSET_EXT_RE.test(lower) || lower.endsWith(".css")) return null;
+		const absolutePath = path.resolve(sourceDirectory, parts.path);
+		let rebasedPath = path.relative(targetDirectory, absolutePath).replaceAll("\\", "/");
+		if (!rebasedPath.startsWith(".")) rebasedPath = `./${rebasedPath}`;
+		return joinUrl({
+			...parts,
+			path: rebasedPath
+		});
+	});
+}
 function isCssFileName(fileName) {
 	return fileName.toLowerCase().endsWith(".css");
 }
@@ -210,4 +227,4 @@ function stripChunkMarkers(code) {
 	return code.replace(CSS_URL_MARKER_PARAM_RE, (_m, leadingQuestion) => leadingQuestion ? leadingQuestion : "");
 }
 //#endregion
-export { markCssUrlAssetReferences, restoreDedupedCssAssetReferences };
+export { markCssUrlAssetReferences, rebaseCssUrlAssetReferences, restoreDedupedCssAssetReferences };

package/dist/build/inject-pregenerated-paths.d.ts

@@ -1,4 +1,7 @@
 //#region src/build/inject-pregenerated-paths.d.ts
+declare global {
+  var __VINEXT_PREGENERATED_CONCRETE_PATHS: unknown;
+}
 declare function injectPregeneratedConcretePaths(root: string): void;
 //#endregion
 export { injectPregeneratedConcretePaths };

package/dist/build/inject-pregenerated-paths.js

@@ -11,7 +11,10 @@ function injectPregeneratedConcretePaths(root) {
 	if (!fs.existsSync(workerEntry)) return;
 	let code = fs.readFileSync(workerEntry, "utf-8").replace(VINEXT_PREGEN_RE, "");
 	const table = readPrerenderManifest(path.join(root, "dist", "server", "vinext-prerender.json"))?.pregeneratedConcretePaths ?? [];
-	if (table.length > 0) code = `${VINEXT_PREGEN_START}\nglobalThis.__VINEXT_PREGENERATED_CONCRETE_PATHS = ${JSON.stringify(table)};\n${VINEXT_PREGEN_END}\n` + code;
+	if (table.length > 0) {
+		globalThis.__VINEXT_PREGENERATED_CONCRETE_PATHS = table;
+		code = `${VINEXT_PREGEN_START}\nglobalThis.__VINEXT_PREGENERATED_CONCRETE_PATHS = ${JSON.stringify(table)};\n${VINEXT_PREGEN_END}\n` + code;
+	} else delete globalThis.__VINEXT_PREGENERATED_CONCRETE_PATHS;
 	fs.writeFileSync(workerEntry, code);
 }
 //#endregion

package/dist/build/prerender-paths.d.ts

@@ -0,0 +1,23 @@
+import { ResolvedNextConfig } from "../config/next-config.js";
+import { VinextRouteRootConfig } from "../config/prerender.js";
+
+//#region src/build/prerender-paths.d.ts
+type PrerenderPathManifest = {
+  buildId?: string;
+  trailingSlash?: boolean;
+  paths: string[];
+};
+declare const PRERENDER_PATH_DISCOVERY_ENV = "__VINEXT_PRERENDER_PATH_DISCOVERY";
+declare const PRERENDER_PATHS_MANIFEST = "vinext-prerender-paths.json";
+type EmitPrerenderPathManifestOptions = {
+  root: string;
+  nextConfigOverride?: Partial<ResolvedNextConfig>;
+  appDir?: string | null;
+  pagesDir?: string | null;
+  routeRootConfig?: VinextRouteRootConfig | null;
+  pagesBundlePath?: string;
+  rscBundlePath?: string;
+};
+declare function emitPrerenderPathManifest(options: EmitPrerenderPathManifestOptions): Promise<PrerenderPathManifest | null>;
+//#endregion
+export { PRERENDER_PATHS_MANIFEST, PRERENDER_PATH_DISCOVERY_ENV, PrerenderPathManifest, emitPrerenderPathManifest };