vinext 0.0.41 → 0.0.43

package/dist/index.d.ts

@@ -1,160 +1,9 @@
 import { NextConfig, NextConfigInput } from "./config/next-config.js";
 import { AppStaticExportOptions, StaticExportOptions, StaticExportResult, staticExportApp, staticExportPages } from "./build/static-export.js";
-import { matchConfigPattern } from "./config/config-matchers.js";
-import { asyncHooksStubPlugin } from "./plugins/async-hooks-stub.js";
-import { _findBalancedObject, _findCallEnd, parseStaticObjectLiteral } from "./plugins/fonts.js";
-import { computeLazyChunks } from "./utils/lazy-chunks.js";
 import { PluginOption } from "vite";
 import { Options } from "@vitejs/plugin-react";
 
 //#region src/index.d.ts
-/**
- * Module-level cache for resolvePostcssStringPlugins — avoids re-scanning per Vite environment.
- * Stores the Promise itself so concurrent calls (RSC/SSR/Client config() hooks firing in
- * parallel) all await the same in-flight scan rather than each starting their own.
- */
-declare const _postcssCache: Map<string, Promise<{
-  plugins: unknown[];
-} | undefined>>;
-/**
- * Resolve PostCSS string plugin names in a project's PostCSS config.
- *
- * Next.js (via postcss-load-config) resolves string plugin names in the
- * object form `{ plugins: { "pkg-name": opts } }` but NOT in the array form
- * `{ plugins: ["pkg-name"] }`. Since many Next.js projects use the array
- * form (particularly with Tailwind CSS v4), we detect this case and resolve
- * the string names to actual plugin functions so Vite can use them.
- *
- * Returns the resolved PostCSS config object to inject into Vite's
- * `css.postcss`, or `undefined` if no resolution is needed.
- */
-declare function resolvePostcssStringPlugins(projectRoot: string): Promise<{
-  plugins: unknown[];
-} | undefined>;
-/**
- * manualChunks function for client builds.
- *
- * Splits the client bundle into:
- * - "framework" — React, ReactDOM, and scheduler (loaded on every page)
- * - "vinext"    — vinext shims (router, head, link, etc.)
- *
- * All other vendor code is left to Rollup's default chunk-splitting
- * algorithm. Rollup automatically deduplicates shared modules into
- * common chunks based on the import graph — no manual intervention
- * needed.
- *
- * Why not split every npm package into its own chunk?
- * - Per-package splitting (`vendor-X`) creates 50-200+ chunks for a
- *   typical app, far exceeding the ~25-request sweet spot for HTTP/2.
- * - gzip/brotli compress small files poorly — each file restarts with
- *   an empty dictionary, losing ~5-15% total compressed size vs fewer
- *   larger chunks (Khan Academy measured +2.5% wire size with 10x
- *   more files containing less raw code).
- * - ES module evaluation has per-module overhead that compounds on
- *   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
- *   well: shared dependencies between routes get their own chunks,
- *   and route-specific code stays in route chunks.
- */
-declare function clientManualChunks(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 const clientOutputConfig: {
-  manualChunks: typeof clientManualChunks;
-  experimentalMinChunkSize: number;
-};
-/**
- * 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";
-};
-declare function getClientOutputConfigForVite(viteMajorVersion: number): {
-  manualChunks: typeof clientManualChunks;
-  experimentalMinChunkSize: number;
-} | {
-  codeSplitting: {
-    minSize: number;
-    groups: {
-      name(moduleId: string): string | null;
-    }[];
-  };
-};
-/**
- * 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)
- *
- * 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.
- */
-declare function getClientTreeshakeConfigForVite(viteMajorVersion: number): {
-  moduleSideEffects: "no-external";
-  preset?: undefined;
-} | {
-  preset: "recommended";
-  moduleSideEffects: "no-external";
-};
-type BundleBackfillChunk = {
-  type: "chunk";
-  fileName: string;
-  imports?: string[];
-  modules?: Record<string, unknown>;
-  viteMetadata?: {
-    importedCss?: Set<string>;
-    importedAssets?: Set<string>;
-  };
-};
-declare function augmentSsrManifestFromBundle(ssrManifest: Record<string, string[]>, bundle: Record<string, BundleBackfillChunk | {
-  type: string;
-}>, root: string, base?: string): Record<string, string[]>;
 type VinextOptions = {
   /**
    * Base directory containing the app/ and pages/ directories.
@@ -243,23 +92,6 @@ type VinextOptions = {
   };
 };
 declare function vinext(options?: VinextOptions): PluginOption[];
-/**
- * Strip server-only data-fetching exports (getServerSideProps,
- * getStaticProps, getStaticPaths) from page modules for the client
- * bundle. Uses Vite's parseAst (Rollup/acorn) for correct handling
- * of all export patterns including function expressions, arrow
- * functions with TS return types, and re-exports.
- *
- * Modeled after Next.js's SWC `next-ssg-transform`.
- */
-declare function stripServerExports(code: string): string | null;
-/** Module-level cache for hasMdxFiles — avoids re-scanning per Vite environment. */
-declare const _mdxScanCache: Map<string, boolean>;
-/**
- * Check if the project has .mdx files in app/ or pages/ directories.
- */
-declare function hasMdxFiles(root: string, appDir: string | null, pagesDir: string | null): boolean;
-declare function scanPublicFileRoutes(root: string): string[];
 //#endregion
-export { type AppStaticExportOptions, type NextConfig, type StaticExportOptions, type StaticExportResult, VinextOptions, asyncHooksStubPlugin as _asyncHooksStubPlugin, augmentSsrManifestFromBundle as _augmentSsrManifestFromBundle, _findBalancedObject, _findCallEnd, hasMdxFiles as _hasMdxFiles, _mdxScanCache, parseStaticObjectLiteral as _parseStaticObjectLiteral, _postcssCache, resolvePostcssStringPlugins as _resolvePostcssStringPlugins, scanPublicFileRoutes as _scanPublicFileRoutes, stripServerExports as _stripServerExports, clientManualChunks, clientOutputConfig, clientTreeshakeConfig, computeLazyChunks, vinext as default, getClientOutputConfigForVite, getClientTreeshakeConfigForVite, matchConfigPattern, staticExportApp, staticExportPages };
+export { type AppStaticExportOptions, type NextConfig, type StaticExportOptions, type StaticExportResult, VinextOptions, vinext as default, staticExportApp, staticExportPages };
 //# sourceMappingURL=index.d.ts.map