import type { PluginOption } from "vite";
import { type PageFileSystemRouterConfig } from "../convention.ts";
import { BaseFileSystemRouter } from "../router.ts";
import { DEFAULT_EXTENSIONS, moduleId } from "./constants.ts";
export { DEFAULT_EXTENSIONS, moduleId };
export { sanitizeChunkFileName, toPickId, treeShake } from "./tree-shake.ts";
export { fileSystemWatcher } from "./fs-watcher.ts";
export interface FileRoutesOptions extends Pick<PageFileSystemRouterConfig, "components" | "httpMethods" | "toPath" | "toRoute"> {
    /** Route directory, relative to the Vite root. Defaults to `src/routes`. */
    dir?: string;
    /** File extensions that participate in routing. Defaults to js/jsx/ts/tsx. */
    extensions?: string[];
    /**
     * A custom file-system router (scanning + convention) used for every Vite
     * environment. Defaults to a `PageFileSystemRouter` over `dir`, configured
     * with the convention options above.
     */
    router?: BaseFileSystemRouter;
    /**
     * Per-environment file-system routers, keyed by Vite environment name.
     * Frameworks (e.g. SolidStart) use this to serve different conventions to
     * client and server environments. Falls back to `router` for environments
     * not listed.
     */
    routers?: Record<string, BaseFileSystemRouter>;
    /** The id the route manifest is served from. Defaults to `virtual:file-routes`. */
    moduleId?: string;
    /**
     * Vite environments whose build should take every route module as an
     * entry, so routes are code-split into their own chunks. Frameworks pass
     * their browser environment's name; the inputs are added to whatever the
     * framework already configures.
     */
    buildInputs?: string | string[];
    /**
     * Deliver `$`-prefixed module refs as code-split dynamic imports, each
     * route its own chunk. The default. Set to `false` to deliver every ref
     * eagerly instead — static imports, `require()`-shaped refs, zero dynamic
     * imports in the output — for the apps where splitting loses: small apps
     * whose per-chunk overhead outweighs the split, and targets that want a
     * single bundle. Adapters need no switch of their own: refs are
     * self-describing (`import()` is code-split, `require()` is eager), and
     * emission adapters branch on the shape they are handed.
     *
     * With `@solidjs/router`, `codeSplitting: false` requires the next release
     * (newer than `2.0.0-next.14`): its adapter must branch on eager refs, and
     * against `next.14` or older, enabling this option fails at first render.
     */
    codeSplitting?: boolean;
    /**
     * Packages that import the virtual module and must therefore stay out of
     * esbuild's dependency prebundling, which cannot resolve it. Emission
     * adapters are expected to take the manifest as an argument instead of
     * importing the virtual module (so app source holds the only import, which
     * prebundling never touches), making this an escape hatch for packages
     * that import it anyway. Defaults to `[]`.
     */
    optimizeDepsExclude?: string[];
    /**
     * Write a declaration for the virtual module typing the manifest as a
     * literal tuple, and keep it in step with the route directory. Routers
     * that derive types from their route table need this: a runtime array
     * tells them nothing, so path-derived types silently degrade without it.
     *
     * `true` writes `file-routes.d.ts` next to the Vite root; pass a path to
     * put it elsewhere. The generated file is self-contained — reference it
     * *instead of* `filesystem-routing/types`, never both.
     */
    types?: boolean | string;
}
/**
 * The Vite delivery adapter for `filesystem-routing`.
 *
 * Serializes the neutral route manifest into the virtual module — module refs
 * become code-split dynamic imports (`$`-prefixed keys) or eagerly required
 * static imports (`$$`-prefixed keys) — and keeps it hot as route files are
 * added, changed and removed.
 *
 * The module serves two views of the same entries: the default export is the
 * flat manifest, and `pageRoutes` is the page entries nested by path with
 * `(group)` segments stripped, so emission adapters don't each reimplement
 * the tree.
 *
 * With `httpMethods` on, one router serves both sides of an SSR app: the
 * handler refs it emits reach server-consumer environments only, and client
 * manifests drop them (and handler-only API entries with them) so handler
 * modules never enter a client build. An environment given its own router
 * via `routers` is explicit and serves that router's manifest untouched.
 */
export declare function fileRoutes(options?: FileRoutesOptions): PluginOption[];