> ## Documentation Index
> Fetch the complete documentation index at: https://stars-components.js.org/llms.txt
> Use this file to discover all available pages before exploring further.

# @wolfstar/cli

> Changelog for @wolfstar/cli: the stars command, dev UI, builders, and diagnostics.

Changes to [`@wolfstar/cli`](https://stars-components.js.org/documentation/packages/cli). For the weekly summary across all packages, see the [changelog overview](https://stars-components.js.org/documentation/changelog/index.md).

## `2.12.0` (2026-10-21)

### New features

* **Remove a subcommand or group** — `stars commands clean --name` accepts the path of a subcommand or a group (`settings server`, `settings group sub`). Discord can't delete one, so the CLI sends the deployed command back with a `PATCH` without that entry, keeping the parent and its other subcommands. Paths under one command share a request. A path that matches nothing still fails with `COMMAND_NOT_FOUND`. ([#351](https://github.com/wolfstar-project/stars-components/pull/351))
* **Last subcommand deletes the command** — Removing a command's last subcommand deletes the command, and the confirmation says so. `--json` output gains a `removed` list next to `deleted`.
* **`stars dev --host [address]`** — Sets the address the application listens on (`HTTP_ADDRESS`, plus `NITRO_HOST`/`HOST` for Nitro). A bare `--host` listens on every interface. The occupied-port check probes that address, and an inferred display URL follows a concrete one. ([#348](https://github.com/wolfstar-project/stars-components/pull/348))
* **`-p` alias** — `-p` is now short for `--port`, as in Nuxt's dev command.

### Updates

* **Ink 8** — The terminal UI now uses `ink` v8. ([#320](https://github.com/wolfstar-project/stars-components/pull/320))
* **Dependencies** — Updated `@wolfstar/vite-server` to `0.5.2`, `@wolfstar/nitro-server` to `0.2.13`.

## `2.11.0` (2026-10-18)

### New features

* **Dev output styles** — Pick Nuxt-style, dashboard, or plain `stars dev` output with `tui.style` or `--style`. `dev.layout` keeps working. ([#344](https://github.com/wolfstar-project/stars-components/pull/344))
* **Startup port checks** — `stars dev` checks local development ports before startup and offers to continue, cancel, or use the next port. Use `--port` or a conflict policy for automation. The chosen port is passed to the runtime.
* **Startup validation** — `stars dev` validates HTTP endpoints and dev listener ports, and reports unwritable development directories before building.

### Updates

* **Display URLs** — Explicit display and health URLs stay independent of the bot listener and are kept across port overrides. In framework mode, unrelated ambient `PORT` values are ignored. Nitro runtime ports are read from `NITRO_PORT` before `PORT`.
* **Dependencies** — Updated `@wolfstar/schema` to `0.12.0`, `@wolfstar/kit` to `0.3.1`, `@wolfstar/nitro-server` to `0.2.12`, `@wolfstar/vite-server` to `0.5.1`.

## `2.10.0` (2026-10-17)

### New features

* **`ctx.addPiecesDir(directory)`** — Modules can register a directory of pieces, with one folder per store (`commands`, `listeners`, …). The pieces are registered before the bot loads, including for `tsc` and `none` builds. `ModulesRuntime` gains `piecesDirs`, `stars info` lists them, and a relative path fails with `MODULE_PIECES_INVALID`. ([#335](https://github.com/wolfstar-project/stars-components/pull/335))
* **Client lifecycle hooks** — `hooks` in `defineModule` accepts `client:preGenericsInitialization`, `client:preInitialization`, `client:postInitialization`, `client:preLoad`, and `client:postListen`. Give each hook by source (`{ from, export }`), a function called with `(client, clientOptions)`. `ctx.addClientHook(name, source)` does the same from `setup`. A module's hooks share one runtime plugin named after it. `ModulesRuntime` gains `clientHooks`, `stars info` lists them, and a bad hook fails with `MODULE_HOOK_INVALID`. ([#337](https://github.com/wolfstar-project/stars-components/pull/337))
* **`ctx.addLocales(directory)`** — Modules can add a directory of locales laid out as `<language>/<namespace>.json`. The locales merge into the client's `i18n` option before `@wolfstar/plugin-i18next` builds its handler, and your project's own languages directory is kept. `ModulesRuntime` gains `locales`, `stars info` lists them, and a bad directory fails with `MODULE_LOCALES_INVALID`. ([#339](https://github.com/wolfstar-project/stars-components/pull/339))
* **`future.compatibilityVersion: 7`** — Opt in to let `stars.config` decide what registers. `@wolfstar/plugin-*` packages in `package.json` are no longer activated by their name. Only the modules in `modules`, and the ones they install, are. `stars build`, `prepare`, `dev`, `info`, and `doctor` warn with `PLUGINS_NOT_REGISTERED` about an installed plugin that is left out. ([#338](https://github.com/wolfstar-project/stars-components/pull/338))

### Updates

* **Registered plugins listed** — On compatibility version 6 and below nothing changes, but `stars info` and `stars doctor` now list the plugins registered by name.
* **Dependencies** — Updated `@wolfstar/schema` to `0.11.0`, `@wolfstar/kit` to `0.3.0`, `@wolfstar/vite-server` to `0.5.0`, `@wolfstar/nitro-server` to `0.2.11`.

### Bug fixes

* **Tunnel error kept when repair fails** — `stars dev --tunnel` keeps reporting the original `cloudflared` error, and enters the `failed` state, when it can't delete the broken binary, instead of rejecting. ([#334](https://github.com/wolfstar-project/stars-components/pull/334))
* **No more dashboard flicker** — The `stars dev` dashboard repaints only the lines that changed instead of rewriting the whole screen on every tick. Switching between the dashboard, the panel, and the overlays redraws the screen once. ([#330](https://github.com/wolfstar-project/stars-components/pull/330))

## `2.9.0` (2026-10-17)

### New features

* **`stars codegen --only <i18n|commands>`** — Runs a single generator. Repeat the flag or comma-separate values to run several. A CI job can now check the i18next types, which only read the locale files, without the bot's secrets or a build. Naming a generator that is off in `stars.config` fails with `CODEGEN_GENERATOR_DISABLED`. ([#329](https://github.com/wolfstar-project/stars-components/pull/329))

### Bug fixes

* **Broken `cloudflared` binary** — `stars dev --tunnel` no longer fails on every run when the downloaded `cloudflared` binary is broken (an interrupted download, or a file without the execute bit). The CLI deletes the file, logs a warning, and opens the tunnel again, once per run. ([#328](https://github.com/wolfstar-project/stars-components/pull/328))

## `2.8.0` (2026-10-09)

### New features

* **varlock reported in `stars.config`** — When a project has a `.env.schema` and `varlock` but `stars.config` does not set `env.loader`, `stars prepare`, `build`, `dev`, and `info` now report it as `VARLOCK_LOADER_IMPLICIT`, or as `VARLOCK_NOT_INSTALLED` when `varlock` is missing. `stars doctor` checks that the schema and `env.loader` agree, flagging a schema with another loader or `loader: 'varlock'` without the package. ([#309](https://github.com/wolfstar-project/stars-components/pull/309))
* **`stars doctor --fix`** — Writes `env: { loader: 'varlock' }` for you. It creates `stars.config.ts` the way `@wolfstar/create-http-framework` scaffolds it, or edits a literal `defineConfig({ ... })` or exported object. When the configuration is too dynamic to edit, it prints the line to add. It asks first (`--yes` answers for you) and never writes in CI or without a terminal.

## `2.7.0` (2026-10-09)

### New features

* **ngrok tunnel provider** — Set `dev.tunnel: { provider: 'ngrok' }` to open the tunnel through ngrok's official Node SDK instead of a `cloudflared` quick tunnel. Add `dev.tunnel.domain` to bind a domain reserved in your ngrok account, so the hostname survives restarts. Install the optional peer `@ngrok/ngrok`, and set `NGROK_AUTHTOKEN` in the environment or the project's `.env`. ([#305](https://github.com/wolfstar-project/stars-components/pull/305))
* **Provider-aware tooling** — The `t` key, `--tunnel`, `stars info`, and `stars doctor` use and report the configured provider. `stars doctor` checks that the ngrok package and authtoken are present.

### Updates

* **`cloudflared` stays the default** — `tunnel: true` and every existing configuration behave as before.
* **`TUNNEL_OPTION_CONFLICT` diagnostic** — `provider` or `domain` next to a `url` you already serve, and `domain` without the `ngrok` provider, are rejected.
* **CLI follows varlock auto-detection** — With `future.compatibilityVersion` 6, a project that depends on `@wolfstar/env-utilities`, has a `.env.schema` (`src/.env.schema`, `.env.schema`, or `varlock.loadPath`), has `varlock` installed, and sets no `env.path` or `env.loader` now resolves the loader to `'varlock'`. `stars dev` and `stars doctor` read variables through `varlock load` instead of dotenv files the bot does not load, and `dev.url` no longer takes its port from those files. ([#308](https://github.com/wolfstar-project/stars-components/pull/308))
* **Dependencies** — Updated `@wolfstar/schema` to `0.10.0`, `@wolfstar/kit` to `0.2.1`, `@wolfstar/nitro-server` to `0.2.10`, `@wolfstar/vite-server` to `0.4.5`.

## `2.6.1` (2026-10-08)

### Bug fixes

* **No spurious redeploy prompts in `stars dev`** — `stars dev` no longer asks you to redeploy commands that did not change. The bot doesn't start or restart while a build is still writing output, and the commands the bot registers are compared with the deployed ones, so a command reported as removed and then re-added no longer prompts. If you accept the prompt while a build runs, `stars dev` refuses with a warning instead of registering an incomplete set of commands. [#302](https://github.com/wolfstar-project/stars-components/pull/302)

## `2.6.0` (2026-10-07)

### New features

* **Module config keys** — A module can read its options from its own top-level `stars.config` key (`meta.configKey`). Once modules are set up, any key that isn't built in and that no installed module claimed is reported as `UNKNOWN_OPTION`, with the claimed keys listed in the fix, so misspelled keys are still errors. The check also runs when `modules` is empty. A `meta.configKey` that is empty, built in, claimed twice, or holds a non-object fails with `MODULE_FAILED`. [#295](https://github.com/wolfstar-project/stars-components/pull/295)
* **Clickable `stars dev` dashboard** — Click a channel or level in the sidebar to show or hide it (like `Space`). Click again, or `Alt`/`Ctrl`-click, to solo it (like `s`). Click a group header to fold it, click a key in the list to run it, and use the wheel to scroll logs. Set `dev.mouse: false` or pass `stars dev --no-mouse` to leave the mouse to your terminal. [#291](https://github.com/wolfstar-project/stars-components/pull/291)
* **`--tunnel` and `--no-tunnel` flags** — `stars dev --tunnel` opens the public tunnel at start regardless of `dev.tunnel` (a `cloudflared` quick tunnel when it's off). `--no-tunnel` keeps it closed at start even when `dev.tunnel` enables it. Both work with `--no-tui`, which prints the URL on the `tunnel` channel. [#290](https://github.com/wolfstar-project/stars-components/pull/290)

### Updates

* **Dependencies** — Updated `@wolfstar/schema` to `0.9.0`, `@wolfstar/kit` to `0.2.0`, `@wolfstar/nitro-server` to `0.2.9`, `@wolfstar/vite-server` to `0.4.4`.

## `2.5.0` (2026-10-06)

### New features

* **Split app and node tsconfigs** — With `future.compatibilityVersion` `6`, `stars prepare` (and `stars dev`/`stars build`) writes `.stars/tsconfig.app.json` for your bot sources and `.stars/tsconfig.node.json` for `stars.config.*`, `vitest.config.*`, `tsdown.config.*`, `vite.config.*` and `scripts/**`, instead of `.stars/tsconfig.json`. `--check` fails when either is outdated, and `stars doctor` and `stars info` report both. [#283](https://github.com/wolfstar-project/stars-components/pull/283)
* **`stars typecheck`** — Regenerates `.stars/` and runs your project's checker (`golar` or `tsc`) once on each project.

### Updates

* **Dependencies** — Updated `@wolfstar/schema` to `0.8.0`, `@wolfstar/kit` to `0.1.3`, `@wolfstar/nitro-server` to `0.2.8`, `@wolfstar/vite-server` to `0.4.3`.

### Migration

* **Solution-style root `tsconfig.json`** — On compatibility version `6`, make your root `tsconfig.json` a solution-style file that references `.stars/tsconfig.app.json` and `.stars/tsconfig.node.json`. A root `tsconfig.json` that still extends `./.stars/tsconfig.json` gets a `TSCONFIG_LEGACY_EXTENDS` warning from `stars prepare` and `stars doctor`. To keep the single `.stars/tsconfig.json`, pin `future.compatibilityVersion` to `5` or `4`.

## `2.4.0` (2026-10-06)

### New features

* **Typed command options with `stars codegen`** — Set `codegen.commands` in `stars.config` (`true`, or `{ output }`, default `src/@types/commands.d.ts`) and `stars codegen` reads the commands from your built bot and writes a `CommandOptionsRegistry` entry per command path (`'ping'`, `'math add'`). Use `Command.OptionsOf<'math add'>` instead of a hand-written `interface Options`: `required` options are non-optional, `choices` become literal unions, and `channel_types` narrow the channel. `stars codegen --check` fails with `CODEGEN_OUTDATED` when the file is stale, and `--json` gives machine-readable output. [#275](https://github.com/wolfstar-project/stars-components/pull/275)

### Updates

* **Dependencies** — Updated `@wolfstar/kit` to `0.1.2`, `@wolfstar/nitro-server` to `0.2.7`, `@wolfstar/schema` to `0.7.0`, `@wolfstar/vite-server` to `0.4.2`.

## `2.3.1` (2026-10-05)

### Bug fixes

* **Tunnel shutdown crash** — `stars dev` no longer crashes with an unhandled `cloudflared exited (code=0, ...) before URL was ready` error when the tunnel closes, for example on Ctrl+C. Shutdown now goes through the normal `stars dev` stop sequence, and a requested close is no longer reported as a tunnel failure. [#270](https://github.com/wolfstar-project/stars-components/pull/270)

## `2.3.0` (2026-10-04)

### New features

* **`stars commands diff` and `stars commands deploy`** — `diff` compares the commands your built bot defines with the ones deployed on Discord (`--check` for CI). `deploy` overwrites them after confirmation (`--yes` for scripts). Both need `@wolfstar/http-framework` 6.1 or later and a built project. [#257](https://github.com/wolfstar-project/stars-components/pull/257)
* **`stars doctor`** — Checks the runtime, framework, credentials, dev port, tunnel and generated files, with a fix for each problem. `--online` also queries Discord, and `--json` is for scripts.
* **Shell completions** — `stars completions <bash|zsh|fish>` prints a completion script. `stars info` now also lists installed modules and the new `dev` options.
* **Log channels and bot bridge** — Dev log entries now have a channel (`cli`, `build`, `bot`, `types`, `tunnel`), a `trace` level and optional detail lines. Use `dev.logs`, `--channel` and `--level` to choose what's shown at start. The log file always receives everything, and `dev.logs.dir` adds one file per run. With `@wolfstar/http-framework` 6.1 or later, the bot reports `hmr`, `commands`, `interactions`, `http` and `lifecycle` events to the CLI over IPC. [#255](https://github.com/wolfstar-project/stars-components/pull/255)
* **Hot reload and command refresh** — With the `Client`'s `hmr` option enabled, builds that only change pieces are hot-reloaded instead of restarting the bot (`dev.hmr: false` always restarts). When registered application commands change, `stars dev` reports it, and with `dev.commands.refresh: 'auto'` the bot redeploys them.
* **Full-screen `stars dev` dashboard** — On terminals of at least 90x20, `stars dev` opens a dashboard with a session sidebar (framework version, uptime, port, tunnel, log file), channel and level filters, and a highlighted log stream with folded stack frames. Switch back to the compact panel with `dev.layout: 'panel'`, `--layout panel` or the `v` key. With `dev.commands.refresh: 'prompt'` (the default), a `Refresh commands? (y/n)` card asks before redeploying. New keys: `d` stops the bot until the next `r`, `v` switches layout, `←`/`→`/`Tab` select a filter, `Space` toggles it, `s` solos it, `a` shows all, `b` groups by channel, `g`/`G` jump to top and back to live, `/` searches. [#256](https://github.com/wolfstar-project/stars-components/pull/256)

### Updates

* **Log file format** — The log file prints each entry's channel (`cli`, `bot`, `types`) where it used to print its source (`stars`, `app`, `tsc`), with detail lines indented under the entry.
* **Dependencies** — Updated `@wolfstar/schema` to `0.6.0`, `@wolfstar/kit` to `0.1.1`, `@wolfstar/nitro-server` to `0.2.6`, `@wolfstar/vite-server` to `0.4.1`.

## `2.2.0` (2026-10-02)

### New features

* **Stars modules** — Add `modules` to `stars.config`: a list of package names or `[name, options]` tuples, installed with [`@wolfstar/kit`](https://stars-components.js.org/documentation/packages/kit)'s `setupModules` before `config:resolved`. The resolved config gains `modules` and `runtime` (the runtime plugins and auto-import presets the modules contributed). Packages listed in `modules` are skipped by the legacy `/register` auto-imports. For the `tsc` and `none` build tools, `stars dev` uses a `node --import` preload, and `stars prepare` writes `.stars/modules.mjs` for production. `stars build`, `stars prepare` and `stars info` warn with `MODULES_PRELOAD_REQUIRED` to point you at it. A failing module is reported as a `MODULE_FAILED` diagnostic (exit code 2). [#247](https://github.com/wolfstar-project/stars-components/pull/247)

### Updates

* **Dependencies** — Updated `@wolfstar/kit` to `0.1.0`, `@wolfstar/schema` to `0.5.0`, `@wolfstar/vite-server` to `0.4.0`, `@wolfstar/nitro-server` to `0.2.5`.

## `2.1.0`

### New features

* **Automatic `env` registration and lifecycle hooks** — Add an `env` option to `stars.config` that mirrors `@wolfstar/env-utilities`' setup options and is registered automatically as the first import of the built entry, before plugin registrations and the bot's own modules. Add Nuxt-style lifecycle `hooks` (`config:resolved`, `env:options`, `prepare:*`, `builder:created`, `tsdown:options`, `build:*`, `dev:*`) run with `hookable`. `future.compatibilityVersion: 5` is now the default: it is version 4 plus the automatic `env` registration, which turns on when the project depends on `@wolfstar/env-utilities` (and stays off with Nitro). Version 4 is still supported. Version 3 is end-of-life: it still works, now reports a `COMPATIBILITY_VERSION_EOL` warning, and will be removed in the next major. Projects generated by `@wolfstar/create-http-framework` with the `tsdown` or `vite` build no longer call `setup()` from `@wolfstar/env-utilities` by hand; `tsc` and JavaScript projects keep it and set `env: false`. ([#243](https://github.com/wolfstar-project/stars-components/pull/243))

### Updates

* **Dependencies** — Updated `@wolfstar/schema` to `0.4.0`, `@wolfstar/vite-server` to `0.3.0`, `@wolfstar/nitro-server` to `0.2.4`.

## `2.0.4`

### Updates

* **Dependencies** — Updated `@wolfstar/schema` to `0.3.0`, `@wolfstar/nitro-server` to `0.2.3`, `@wolfstar/vite-server` to `0.2.4`.

## `2.0.3`

### Updates

* **Dependencies** — Updated all non-major dependencies.
* **Dependencies** — Updated `@wolfstar/nitro-server` to `0.2.2`, `@wolfstar/schema` to `0.2.1`, `@wolfstar/vite-server` to `0.2.3`.

## `2.0.2`

### Bug fixes

* **Plugin registration version requirement** — Require `@wolfstar/vite-server` `^0.2.2`, so upgrading the CLI always brings the plugin registration fix from [#222](https://github.com/wolfstar-project/stars-components/issues/222) (only packages exporting `/register` get their registration injected) instead of keeping a locked `0.2.1` that crashes builds depending on `@wolfstar/plugin-cache`, `@wolfstar/plugin-gateway` or `@wolfstar/plugin-sharder` with `ERR_PACKAGE_PATH_NOT_EXPORTED`. ([#231](https://github.com/wolfstar-project/stars-components/pull/231))

## `2.0.1`

### Updates

* **Dependencies** — Updated all non-major dependencies.
* **Dependencies** — Updated `@wolfstar/nitro-server` to `0.2.1`, `@wolfstar/vite-server` to `0.2.1`.

## `2.0.0`

### Updates

* **Dependencies** — Updated `@wolfstar/schema` to `0.2.0`, `@wolfstar/nitro-server` to `0.2.0`, `@wolfstar/vite-server` to `0.2.0`.

### New features

* **Dedicated Vite and Nitro builder packages** — Extract optional Vite and Nitro builders into dedicated server packages ([`@wolfstar/vite-server`](https://stars-components.js.org/documentation/changelog/stars-components/vite-server) and [`@wolfstar/nitro-server`](https://stars-components.js.org/documentation/changelog/stars-components/nitro-server)), with a shared host context and builder lifecycle contract in schema. Preserve CLI configuration, lazy loading, project-local dependencies, and plugin registration. ([#209](https://github.com/wolfstar-project/stars-components/pull/209))

### Updates

* **Dependencies** — Updated `@wolfstar/schema` to `0.2.0`, `@wolfstar/nitro-server` to `0.2.0`, `@wolfstar/vite-server` to `0.2.0`.

## `1.0.0`

### Updates

* **Dependencies** — Updated `@wolfstar/http-framework` to `5.0.0`.

### New features

* **Nitro builds (experimental)** — Implemented `experimental.enableNitro`: `stars dev`/`stars build` now build the bot through [Nitro](https://nitro.build) v3's own Vite plugin (`nitro/vite`, requires Vite 8) instead of refusing with `EXPERIMENT_UNAVAILABLE`. `@wolfstar/http-framework`: `Client` now has a `fetch(request, options?)` method, the Web `Request`/`Response` counterpart of `listen()`, running the exact same signature verification, routing and replies without binding a port, for anything that speaks Fetch instead of `node:http` (Nitro, a Worker, `Bun.serve`, `Deno.serve`, Vite's own dev middleware). The Discord public key is imported once and reused across calls, the same lifetime `listen()` gives its own signing key. The previously-unannounced `@wolfstar/http-framework/fetch` submodule (`createFetchHandler`/`FetchHandler`/`FetchHandlerOptions`) is removed in favour of this. `@wolfstar/cli`: Nitro v3 is itself a Vite plugin, so the new `NitroBuilder` reuses the project's own `vite.config.*`/`stars.config#vite` the same way `build.tool: 'vite'` does, and adds a generated server entry on top: it imports the entry's default export (the `Client` instance, already `load()`ed rather than `listen()`ed) and calls `client.fetch(request)`, in the plain `{ fetch(Request): Promise<Response> }` shape Nitro's own server entry convention expects. `stars build` now produces `.output/` laid out for the configured `experimental.nitro.preset` (`node-server` by default, deployable to anything Nitro targets: `cloudflare-module`, `aws-lambda`, `vercel`, `netlify`, `bun`, `deno-deploy`, and more) instead of a `node:http` process; `stars dev` rebuilds and restarts on every change, the same as the other build tools. Install `nitro` (and `vite`) as a dev dependency to use it. The now-implemented `EXPERIMENT_UNAVAILABLE` diagnostic code is removed from `cliDiagnostics`/`CliDiagnosticCode`. `@wolfstar/cli`: `NitroBuilder` also turns on Vite's native `resolve.tsconfigPaths`, and `stars prepare`'s generated `.stars/tsconfig.json` now emits the same `~`/`@`/`~~`/`@@` aliases `build.tool: 'tsdown'` already gets whenever `experimental.enableNitro` is on. ([#207](https://github.com/wolfstar-project/stars-components/pull/207))

### Updates

* **Dependencies** — Updated `@wolfstar/http-framework` to `5.0.0`.

## `0.7.0`

### New features

* **Colour themes for `stars dev`** — `stars dev` now has colour themes, like Claude Code. Press `T` in the interactive UI to preview and pick `dark`, `light`, the colour-blind friendly `dark-daltonized`/`light-daltonized`, the terminal-palette-only `dark-ansi`/`light-ansi`, or `auto` (follows the terminal background). The choice is saved to `~/.config/stars/preferences.json` (`$XDG_CONFIG_HOME`, `%APPDATA%` or `$STARS_CONFIG_DIR`). `--theme <name>` and `STARS_THEME` override the saved theme for one run. The UI now paints with semantic theme colours, so body text keeps the terminal's own foreground and stays readable on light backgrounds. ([#204](https://github.com/wolfstar-project/stars-components/pull/204))
* **Turborepo-style shutdown** — `stars dev` now shuts down like Turborepo: the first `Ctrl+C` (or `SIGINT`/`SIGTERM`/`SIGHUP`) stops the bot gracefully and prints a hint, a second one kills the bot and its helper processes right away instead of waiting for `dev.killTimeout`. ([#201](https://github.com/wolfstar-project/stars-components/pull/201))
* **Readable crash reports** — Render unexpected errors (and `stars dev` startup crashes) as sourcemapped, syntax-highlighted reports through `my-bad`, the way `nuxt` does, instead of a raw stack trace into the bundled `dist`. Errors the CLI already explains (`CliError`, `ConfigError`) keep their short message and hint. `runMain` is now exported for programmatic use, and the package's sources are reorganised after `nuxt/cli` (`commands/`, `dev/`, `builders/`, `utils/`, `main.ts`, `run.ts`) with no change to the `stars` commands or the public exports. ([#200](https://github.com/wolfstar-project/stars-components/pull/200))

## `0.6.1`

### Bug fixes

* **Quick tunnel reliability** — Fixed the `dev.tunnel` quick tunnel: it now opens the `cloudflared` tunnel through `untun` instead of spawning `cloudflared` directly and scraping its stdout for the URL with a regex. `untun` manages the `cloudflared` binary itself (downloading it if missing) and exposes the tunnel URL and lifecycle programmatically, which also fixes the tunnel never closing when spawning `cloudflared` failed silently. ([#195](https://github.com/wolfstar-project/stars-components/pull/195))

## `0.6.0`

### New features

* **Auto-registered WolfStar plugins** — Automatically activate `@wolfstar/plugin-*` dependencies during bundler builds by injecting each plugin's `/register` side-effect entrypoint before the application entry. ([#192](https://github.com/wolfstar-project/stars-components/pull/192))

## `0.5.0`

### New features

* **Generated TypeScript alias config** — Generate an extendable `.stars/tsconfig.json` during prepare, dev and build with TypeScript paths matching tsdown aliases, and extend it in scaffolded projects. Include Sapphire base, extra-strict, and decorators compiler options in the generated configuration, with ESNext/Bundler and noEmit for bundler builds. Align bundler compiler options with Nitro: isolated modules, verbatim syntax, JavaScript sources, explicit TypeScript extensions, package imports, and web API types. ([#191](https://github.com/wolfstar-project/stars-components/pull/191))

### Updates

* **Dependencies** — Updated all non-major dependencies.
* **Dependencies** — Updated `@wolfstar/http-framework` to `4.0.1`.

## `0.4.0`

### New features

* **Convention-first workflow** — Make the Stars workflow convention-first: compatibility version 4 is now the default, `stars dev` forces development mode, `src/locales` is copied and watched automatically, and environment files are discovered under both `src/` and the project root. The interactive dev UI now supports `t` to open or close a public quick tunnel without configuring `dev.tunnel`. ([#182](https://github.com/wolfstar-project/stars-components/pull/182))

### Updates

* **Dependencies** — Updated `@wolfstar/http-framework` to `4.0.0`.

## `0.3.0`

### New features

* **Nuxt-style dev panel and folded logs** — Align the `stars dev` terminal UI with Nuxt's pinned panel and folded logs. The tsdown builder now leaves dependencies external with `deps.neverBundle`, removing the deprecated option and keeping shared dependencies external for dynamically loaded pieces. Its entry list, target and output-size table are suppressed; warnings and errors remain available in the log browser and log file. The bottom-aligned panel displays an animated Stars wordmark, aligned URLs, actual build-phase progress and elapsed time, then readiness timing and diagnostic counts. `dev.banner` accepts custom text/lines or `false` to hide the wordmark. Log, help and session-info views use the alternate screen and restore the panel when closed. Logs support search, source/level filters, selection, copying, and jumping to the last error with context. Stack frames are dimmed and no longer counted as separate errors; Node warnings are classified as warnings rather than errors. Rebuild state and duration now reset on Rolldown's per-build hook, including recovery from a failed build. Reduced motion preserves the elapsed clock, and redirected input, dumb terminals and small panes get a safe plain fallback. ([#168](https://github.com/wolfstar-project/stars-components/pull/168))

### Updates

* **Dependencies** — Updated all non-major dependencies.
* **Dependencies** — Updated dependency chokidar to v5.
* **Dependencies** — Updated `@wolfstar/http-framework` to `3.6.0`.

## `0.2.0`

### New features

* **`tsdown` build from `stars.config`** — Build `tsdown` from `stars.config`, and wire auto imports into it. `stars build` and `stars dev` now derive the whole `tsdown` build from `stars.config`, so a base project configures nothing: every source file next to `entry` (minus `*.test.*`/`*.spec.*`), emitted one-to-one so the stores keep loading pieces from `dist/commands` at runtime, ESM on `platform: 'node'`, the project's tsconfig, sourcemaps and treeshaking on, minification off, dependencies left in `node_modules` (`deps.skipNodeModulesBundle`), no declaration files, and the output extension `build.output` implies. The build also ships Nuxt's alias prefixes: `~` and `@` resolve to the entry's directory, `~~` and `@@` to the project root. A target written as a relative path (`'./src/lib'`) is resolved against the project root the way every other path in `stars.config` is. The project's `tsdown` block is layered on top: its values win, and its `plugins` and `alias` entries are added to what `stars` contributes rather than replacing them. The auto imports plugin is injected by the CLI instead of by the project's own configuration file, so `future: { compatibilityVersion: 4 }` is all a project needs for the framework's exports and its `src/lib/**`, `src/utils/**` to be usable without an `import` statement. With `future.compatibilityVersion: 3` a `tsdown.config.*` still drives the build and everything above is merged over it, so options can move across one at a time. The `vite` block finally reaches Vite too: it was resolved and validated, but never passed to `vite.build()`. `stars info` gains a `Future` section with the compatibility version in effect, and two `Build` rows: the file the build tool is configured from, and the option names the `tsdown`/`vite` block sets. ([#164](https://github.com/wolfstar-project/stars-components/pull/164))

### Updates

* **Dependencies** — Updated `@wolfstar/http-framework` to `3.5.0`.

## `0.1.0`

### New features

* **`stars dev` loop completion** — Round out the `stars dev` loop with the pieces a Discord bot needs while developing: `dev.typecheck` runs a type checker next to the bot and reports type errors on the dev UI's own `tsc` channel, without blocking builds or restarts. `dev.typecheck.checker` selects `tsc`, `golar` (`golar tsc`) or `tsz`, and defaults to `auto`: `golar` when the project depends on it, `tsc` otherwise. `tsc` and `golar` watch the project themselves; `tsz`, which has no watch mode, is re-run after every build. `dev.tunnel` exposes the bot's interactions endpoint publicly, either through a `cloudflared` quick tunnel (`true`) or an https URL you already serve (a string), so Discord can reach it. `dev.tunnel.updateEndpoint` writes that URL to the Discord application's `interactions_endpoint_url` and is opt-in. `dev.logFile` (default `.stars/dev.log`) mirrors a dev session's logs to disk, so a run can be read back after the terminal UI is gone. `stars commands` lists and cleans the application commands Discord has deployed (`--guild`, `--name`, `--yes`, `--json`), which is how renamed or removed commands get cleared. `stars info` now reports the auto imports and the new `dev` options too. The interactive `stars dev` UI is now an [Ink](https://github.com/vadimdemedes/ink) (React) application: the same keys and layout, rebuilt as components, with the terminal's alternate screen handled by Ink itself. `@wolfstar/cli` therefore requires Node 22 or newer (Ink's own requirement); plain mode is unchanged and still takes over on non-interactive output, in CI and with `--no-tui`. `stars commands clean` without `--name`/`--yes` now runs an interactive wizard: a checklist of the deployed commands, then a confirmation, instead of an all-or-nothing prompt. ([#158](https://github.com/wolfstar-project/stars-components/pull/158))
* **Typed project configuration and the `stars` CLI** — Mirroring how Nuxt splits `nuxt.config`/`defineNuxtConfig` (owned by the `nuxt` framework) from `nuxi` (a separate CLI that calls into it), the typed `stars.config.{ts,mts,cts,js,mjs,cjs}` schema and loader are owned by `@wolfstar/http-framework` (`@wolfstar/http-framework/config`: `defineConfig`, `loadStarsConfig`, `ConfigError`), not by the CLI. Any tool can resolve a project's configuration without depending on `@wolfstar/cli`. The config module has no side effects; importing it (or a `stars.config.ts` that imports it) never starts the bot. Configuration is discovered from the working directory or passed with `--config`, paths are resolved from the file, every option has a default, and invalid options raise a `ConfigError` with a stable code, the offending option path, the file, and an actionable hint. `@wolfstar/cli` ships the `stars` binary that consumes it: `dev`, `build`, `info`, `codegen`. `stars dev` builds through the project's `tsdown` or `tsc` (or plain-watches JavaScript projects), starts the bot and restarts it after every successful build. `dev.url` needs no configuration: it is detected from `HTTP_PORT` (env var, `.env.local`/`.env`, or `dev.env`) or `3000`, the way Vite's and Nuxt's dev servers do, and `localhost` is swapped for `127.0.0.1` at runtime if that is what is actually reachable. On a terminal it renders an interactive UI (lifecycle, uptime, restart reason, build state, URL/health, filtered logs, `r` restart, `c` clear, `h`/`?` help, `q` quit); `--no-tui`, `STARS_TUI=plain`, CI and redirected output switch to plain line output. Both modes honour `NO_COLOR`, reduced motion, and stop the bot cleanly on `SIGINT`/`SIGTERM` with consistent exit codes. `ConfigError`s from the framework are reported with exit code `2`. `stars build` runs the build tool once (exit code `3` on failure). `stars info [--json]` prints the resolved configuration and environment. `stars codegen [--check] [--json]` runs the i18next type generation. `stars --help` and `stars --version` never load the configuration machinery, so they stay fast. ([#158](https://github.com/wolfstar-project/stars-components/pull/158))
* **Experimental config block** — Add an `experimental` block to `stars.config.*`, in the shape Nuxt's own `experimental` config has: opt-in booleans, all `false` by default, each documented with what it changes and what it still needs. `experimental.enableVite` lets a project build through its own `vite` instead of `tsdown` (`build.tool` accepts `'vite'` only with the flag on, and `'auto'` only then detects a `vite.config.*`). `experimental.enableExternalVite` leaves the build to the project: `stars dev` starts no build of its own, it watches what the external one writes and restarts the bot, keeping restarts, health, the tunnel, type checking and the panel working. `experimental.enableNitro` is declared but not implemented yet: it needs the framework's Fetch adapter, so `stars dev`/`stars build` refuse it with an actionable error instead of silently ignoring it. `stars info` reports which flags are on. ([#158](https://github.com/wolfstar-project/stars-components/pull/158))

### Updates

* **Dependencies** — Updated `@wolfstar/http-framework` to `3.4.0`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.