Contribute a raw blueprint statement to the built application.
The statement is injected verbatim into the generated entry's configure step, where a
local blueprint is in scope (e.g. blueprint.set('stone.i18n.resources', {...})). Prefer
addModule for anything expressible as a module; reach for this only when you must run
imperative configuration at app startup.
A JavaScript statement executed with blueprint in scope.
Contribute a module to the built application.
The specifier is imported by the generated entry point and its exports are collected into
the app's modules (exactly like the user's own app/** modules), so a plugin can inject
decorated classes, blueprints or defineBuilderConfig(...) meta-modules. Use a specifier that
resolves from .stone/tmp (a relative path like ./plugins/x.mjs, or a bare package name).
An import specifier resolvable from .stone/tmp.
The build blueprint. Read stone.builder.* here, or set config the built app will read.
Resolve a path inside the .stone/tmp build directory (where generated entries live).
Path segments joined under .stone/tmp.
The absolute path.
The command currently driving the lifecycle: 'build', 'dev', 'preview', 'export', ...
The incoming console event driving the build (carries CLI flags and arguments).
The branded reporter, for user-facing output that matches the CLI's own look.
Write a file into the .stone/tmp build directory, creating parent directories as needed.
The path, relative to .stone/tmp.
The file content.
The absolute path written.
The context handed to a plugin's build-phase hooks.
This is a deliberately small, stable facade over the CLI's internal build context: plugin authors depend on these helpers, never on the CLI internals, so the CLI can evolve without breaking published plugins. Everything a plugin needs to participate in a build is here: read/mutate the blueprint, learn which command is running, report to the user, and generate code into the
.stone/build directory.