Automation

Add --yes (or -y) to run a CLI command without prompts. Supply the component names and framework explicitly so the script has everything it needs.

After the CLI is installed and hulla ui init has recorded the framework and output paths, a package script can add known components. Package scripts find the locally installed executable automatically; a direct CI shell command needs node_modules/.bin on its search path, as shown in the quick start.

hulla ui add --yes --framework astro button dialog

If the component appears in more than one framework, --framework is required in non-interactive mode. Component names are required too; hulla ui add --yes with no names fails with a message asking for them.

hulla init --yes can create project settings without asking to confirm. UI initialization may need framework, path, or registry choices; run it once interactively, review and commit .hulla/ui.json, then let repeatable add commands run in CI.

Pin the CLI beta version in the project and use a pinned registry source. This makes CLI behavior and copied component inputs reviewable alongside the resulting source changes. See Configuration for the files to commit.

The CLI does not run the consuming application’s full test suite for you. After adding or updating files, run the application’s own checks and inspect the Git diff. In CI, git diff --exit-code can detect when a supposedly repeatable command changed committed files.

hulla ui add --yes --framework astro button dialog
git diff --exit-code
bun run check

bun run check assumes the consuming app defines a check script; use your repository’s own validation command.

If a command fails, start with the missing input or file named in its message:

For interactive setup and component update behavior, see UI components. The legacy hulla api generator commands are not part of the current @hulla/api 2.0 workflow; see API commands for that compatibility boundary.