Stone.js API
    Preparing search index...

    Interface BuilderConfig

    Configuration for building the Stone.js application.

    interface BuilderConfig {
        assets?: AssetsConfig;
        autoDiscoverPlugins?: boolean;
        browser?: { excludedModules?: string[] };
        builders?: Record<string, StoneBuilderDefinition>;
        dotenv?: Partial<DotenvConfig>;
        imperative?: boolean;
        input?: InputConfig;
        language?: "typescript" | "javascript";
        lazy?: boolean;
        output?: string;
        plugins?: StoneCliPlugin[];
        public?: string;
        rendering?: "csr" | "ssr" | "ssg";
        rollup?: RollupConfig;
        server?: { printUrls?: boolean };
        ssg?: { params?: Record<string, string[]>; routes?: string[] };
        target?: string;
        test?: TestConfig;
        vite?: Partial<UserConfig>;
        watcher?: { ignored?: string[] };
    }
    Index
    assets? autoDiscoverPlugins? browser? builders? dotenv? imperative? input? language? lazy? output? plugins? public? rendering? rollup? server? ssg? target? test? vite? watcher?
    assets?: AssetsConfig

    Static asset import aliases for components (client and SSR).

    Lets components import assets with short, stable aliases instead of brittle relative paths, e.g. import logo from '@img/logo.png'. Each alias resolves to a subfolder of assets.dir under the project root. Applied to dev, build, client and SSR via Vite's resolve.alias; user builder.vite.resolve.alias still wins.

    autoDiscoverPlugins?: boolean

    Whether to auto-discover first-party (@stone-js/*) CLI plugins (default true).

    When enabled, @stone-js/* packages in the project's direct dependencies that advertise a stone.cliPlugin contract are loaded automatically, so first-party modules stay truly zero-config. Third-party plugins are never auto-discovered: they must be declared in plugins. Set to false to opt out entirely and load every plugin explicitly.

    browser?: { excludedModules?: string[] }

    The browser configuration for the application.

    Type Declaration

    • OptionalexcludedModules?: string[]

      Modules to be removed from the browser build.

    builders?: Record<string, StoneBuilderDefinition>

    The registered build targets, keyed by name.

    The CLI drives whichever one answers and knows nothing about what it does, so a module owns its own build: add a target here (or from a plugin's blueprintMiddleware) and stone build --target <name> drives it. The two the CLI ships with are registered the same way.

    dotenv?: Partial<DotenvConfig>

    Environment variable management configuration.

    imperative?: boolean

    Whether the application is using imperative programming style.

    input?: InputConfig

    Module autoloading configuration.

    language?: "typescript" | "javascript"

    The language used in the application.

    lazy?: boolean

    Whether the application is using lazy loading for pages, error pages and layouts.

    output?: string

    The output file path for the production build.

    plugins?: StoneCliPlugin[]

    CLI plugins that participate in the build/bundle lifecycle.

    This is the explicit, primary path, open to any package: list the plugins a module exposes (e.g. plugins: [i18nCliPlugin()]). First-party @stone-js/* plugins are additionally auto-discovered from their package.json contract (see autoDiscoverPlugins); a plugin listed here always wins over the same plugin auto-discovered.

    public?: string

    The public directory served/copied verbatim (defaults to public).

    rendering?: "csr" | "ssr" | "ssg"

    Whether the application is using server-side rendering.

    rollup?: RollupConfig

    The rollup configuration for the application.

    server?: { printUrls?: boolean }

    The HTTP server configuration for the application.

    Type Declaration

    • OptionalprintUrls?: boolean

      Should print or not the URLs of the server.

    ssg?: { params?: Record<string, string[]>; routes?: string[] }

    Static Site Generation options (used with rendering: 'ssg' / --ssg).

    Type Declaration

    • Optionalparams?: Record<string, string[]>

      The values a dynamic segment can take at build time, by segment name.

      A parameterized path cannot be pre-rendered until someone says what its segments contain. Declaring them here expands the path instead of skipping it, which matters most for a parameterized router prefix: one :lang on the prefix puts a dynamic segment on every route, and auto-discovery would otherwise collapse to nothing.

      An optional segment also yields the path without it, so /:lang?/about with { lang: ['en', 'fr'] } pre-renders /about, /en/about and /fr/about.

      Only finite, enumerable segments belong here; anything data-driven stays in routes.

    • Optionalroutes?: string[]

      Extra routes to pre-render, added to the ones derived from your pages. Use it for paths no declaration can produce (a CMS-driven slug, per-entry data).

    target?: string

    The application target.

    test?: TestConfig

    The test run configuration.

    vite?: Partial<UserConfig>

    The Vite configuration for the application.

    watcher?: { ignored?: string[] }

    File watching configuration.

    Type Declaration

    • Optionalignored?: string[]

      Files to be ignored during watching.

    Settings
    Member Visibility

    On This Page
    Properties