Stone.js API
    Preparing search index...

    Interface StoneBuilderDefinition

    A build target the CLI can drive.

    The CLI knows when to call a builder and nothing about what it does, which is what lets a module own its own build: @stone-js/use-react knows how to build a React application, @stone-js/use-react-native delegates to Expo, and a third-party library declares its own target the same way. None of them require a change here.

    A definition is registered under stone.builder.builders.<target>, either by a StoneCliPlugin's blueprintMiddleware or directly in stone.config.

    interface StoneBuilderDefinition {
        devEntry?: (blueprint: IBlueprint) => string;
        devMode?: "supervised" | "self-hosted";
        match: (blueprint: IBlueprint, event: IncomingEvent) => boolean;
        previewEntry?: (blueprint: IBlueprint) => string;
        priority?: number;
        resolver: (context: ConsoleContext) => StoneBuilder;
        target: string;
    }
    Index
    devEntry? devMode? match previewEntry? priority? resolver target
    devEntry?: (blueprint: IBlueprint) => string

    What stone serve should launch for a self-hosted target, if anything.

    The React target generates a Vite dev server and needs it launched and followed. A target that delegates to another tool returns nothing: that tool's own process is the dev server, and there is nothing left for the CLI to supervise.

    devMode?: "supervised" | "self-hosted"

    How stone serve should supervise this target's dev server.

    • supervised: the CLI watches the sources, rebuilds and restarts the child. What a backend build needs, since nothing else reloads it.
    • self-hosted: the builder's own dev step owns reloading (Vite's HMR, Expo's dev server), so the CLI launches it and follows its exit code instead of restarting it.

    Declaring the capability rather than letting the command match on a target name is what keeps stone serve from having to know which targets exist.

    match: (blueprint: IBlueprint, event: IncomingEvent) => boolean

    Whether this target should answer, when nobody named one explicitly.

    Detection only: the flag and the configured target are handled before this is consulted, so a definition never has to re-implement that precedence.

    previewEntry?: (blueprint: IBlueprint) => string

    Where stone preview should start the built application from.

    A React build is served by a generated preview server, a backend build by its own bundle, and a native build by neither. Asking the target rather than assuming keeps the command from knowing which is which.

    priority?: number

    Order among the definitions whose match could answer, ascending.

    Spaced by tens, so a module can slot a target between two existing ones. The fallback target that answers anything sits last on purpose.

    resolver: (context: ConsoleContext) => StoneBuilder

    Build the builder for this run.

    target: string

    The target's name, as --target <name> and stone.builder.target spell it.

    Settings
    Member Visibility

    On This Page
    Properties