> ## 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/schema > Changelog for @wolfstar/schema: the stars.config.* schema and loader move out of @wolfstar/http-framework, and config errors become structured diagnostics. Changes to [`@wolfstar/schema`](https://stars-components.js.org/documentation/packages/schema). For the weekly summary across all packages, see the [changelog overview](https://stars-components.js.org/documentation/changelog/index.md). ## `0.12.0` (2026-10-18) ### New features * **`tui.style`** — Configure Nuxt-style, dashboard, or plain `stars dev` output. `dev.layout` keeps working. ([#344](https://github.com/wolfstar-project/stars-components/pull/344)) * **Port conflict policies** — Configure how `stars dev` handles an occupied development port for automation. ### 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`. ## `0.11.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 `/.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. ## `0.10.0` (2026-10-09) ### New features * **ngrok tunnel provider** — `dev.tunnel` accepts `provider: 'ngrok'` and a `domain` reserved in your ngrok account. `cloudflared` stays the default. The schema exports `TUNNEL_PROVIDERS` and `DEFAULT_TUNNEL_PROVIDER`, and `ResolvedTunnelConfig` quick mode now carries `provider` and `domain`. Conflicting options fail with `TUNNEL_OPTION_CONFLICT`. ([#305](https://github.com/wolfstar-project/stars-components/pull/305)) * **`detectVarlock(root)`** — Inspects a project's `.env.schema`, `varlock` installation, and dependency. ([#308](https://github.com/wolfstar-project/stars-components/pull/308)) ### Updates * **varlock loader follows the runtime** — With `future.compatibilityVersion` 6, a project that depends on `@wolfstar/env-utilities`, has a `.env.schema`, has `varlock` installed, and sets no `env.path` or `env.loader` now resolves `ResolvedEnvConfig.loader` to `'varlock'`. `ResolvedEnvConfig.options` still holds what `stars.config` wrote. ## `0.9.0` (2026-10-07) ### New features * **Module config keys** — Top-level `stars.config` keys that aren't built in are kept as `ResolvedStarsConfig.moduleOptions` instead of rejected, so a module can read its options from its own key (`meta.configKey`). `BUILT_IN_CONFIG_KEYS` lists the keys the schema owns, `assertModuleOptionsClaimed` reports the first unclaimed key as `UNKNOWN_OPTION`, and `ModulesRuntime.configKeys` carries the keys modules claimed. Augment the `StarsConfig` interface to type your module's key. [#293](https://github.com/wolfstar-project/stars-components/pull/293) * **`dev.mouse` option** — Controls mouse support in the `stars dev` dashboard (default `true`). Set it to `false`, or pass `stars dev --no-mouse`, to leave the mouse to your terminal. [#291](https://github.com/wolfstar-project/stars-components/pull/291) ### Migration * **`ModulesRuntime.configKeys` is required** — If you build a `ModulesRuntime` literal, add `configKeys`, or start from `EMPTY_MODULES_RUNTIME`, which already has it. ## `0.8.0` (2026-10-06) ### New features * **Compatibility version `6`** — `future.compatibilityVersion` `6` is now the latest and the default, gated by the new `SPLIT_TSCONFIG_VERSION` constant. A `tsdown` build's default `build.tsconfig` becomes the generated `.stars/tsconfig.app.json`, and `dev.typecheck.projects` lists what `stars typecheck` checks (`DEFAULT_APP_TSCONFIG`, `DEFAULT_NODE_TSCONFIG`). A `tsc` or `none` project keeps its own tsconfig and gets the node config on top. Pin `5` or `4` to keep the single `.stars/tsconfig.json`. [#282](https://github.com/wolfstar-project/stars-components/pull/282) ## `0.7.0` (2026-10-06) ### New features * **`codegen.commands`** — Set `codegen.commands` (`true`, or `{ output }`, default `src/@types/commands.d.ts`) so `stars codegen` generates a `CommandOptionsRegistry` from your built bot, read by `Command.OptionsOf<'math add'>`. `stars codegen --check` fails with `CODEGEN_OUTDATED` when the file is stale. [#275](https://github.com/wolfstar-project/stars-components/pull/275) ### Updates * **Dependencies** — Updated all non-major dependencies ([#253](https://github.com/wolfstar-project/stars-components/pull/253)). ## `0.6.0` (2026-10-04) ### New features * **`stars dev` options** — New `dev.layout` (`'auto' | 'dashboard' | 'panel'`), `dev.logs` (`channels` and `levels` shown at start, `dir` and `keep` for one log file per run), `dev.commands.refresh` (`'prompt' | 'auto' | 'off'`) and `dev.hmr`. An unknown value for a fixed-choice option is reported with the new `INVALID_CHOICE` diagnostic. `LOG_LEVELS` and `DEFAULT_LOG_LEVELS` are exported. [#254](https://github.com/wolfstar-project/stars-components/pull/254) * **Node env loader** — `env.loader` accepts `'node'`, and the loader is auto-detected when you leave it unset. [#265](https://github.com/wolfstar-project/stars-components/pull/265) ## `0.5.0` (2026-10-02) ### New features * **`modules` option** — Add `modules` to `stars.config`: a list of package names or `[name, options]` tuples, installed by the CLI 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). A failing module is reported as a `MODULE_FAILED` diagnostic, and `MODULES_PRELOAD_REQUIRED` warns when a `tsc` or `none` build needs the `.stars/modules.mjs` preload. [#247](https://github.com/wolfstar-project/stars-components/pull/247) ## `0.4.0` ### New features * **`env` in `stars.config`** — Added a top-level `env` option that mirrors `@wolfstar/env-utilities`' setup options. It is registered automatically as the first import of the built entry, before plugin registrations and the bot's own modules. * **Lifecycle hooks** — Added Nuxt-style hooks (`config:resolved`, `env:options`, `prepare:*`, `builder:created`, `tsdown:options`, `build:*`, `dev:*`) run with `hookable`. ### Migration * `future.compatibilityVersion: 5` is now the default. It is version 4 plus the automatic `env` registration, which activates 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 but 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)). ## `0.3.0` ### Updates * **Decorators split into new package** — Moved the utility decorators out of `@wolfstar/http-framework` into a new package, [`@wolfstar/decorators`](https://stars-components.js.org/documentation/changelog/stars-components/decorators), mirroring the split between `@sapphire/framework` and `@sapphire/decorators`. * **Breaking (`@wolfstar/http-framework`):** `ApplyOptions`, `RequiresGuildContext`, `RequiresDMContext`, `RequiresUserPermissions`, `RequiresClientPermissions`, `Enumerable`, `EnumerableMethod`, `createClassDecorator`, `createMethodDecorator`, `createProxy`, `createFunctionPrecondition`, and the `PieceConstructor`/`ContextFallback` types are no longer exported by the framework. Install `@wolfstar/decorators` and import them from there instead; their behaviour is unchanged. The `Register*` decorators and `RestrictGuildIds` stay in the framework. * `@wolfstar/decorators` declares `@wolfstar/http-framework` as a peer dependency. * `@wolfstar/schema` now includes `@wolfstar/decorators` in the default `imports.presets`, so projects using the `stars` CLI's auto imports keep getting the decorators without an explicit import once the package is installed ([#238](https://github.com/wolfstar-project/stars-components/pull/238)). ## `0.2.1` ### Updates * **Dependencies** — Updated all non-major dependencies ([#227](https://github.com/wolfstar-project/stars-components/pull/227)). ## `0.2.0` ### New features * **Separate Vite and Nitro builder packages** — The optional Vite and Nitro builders are now dedicated server packages with a shared host context and builder lifecycle contract in [`@wolfstar/schema`](https://stars-components.js.org/documentation/changelog/stars-components/schema). CLI configuration, lazy loading, project-local dependencies, and plugin registration are preserved ([#209](https://github.com/wolfstar-project/stars-components/pull/209)). * **Nuxt-style configuration entry points** — Aligned configuration entry points with Nuxt by adding framework schema and package metadata exports, a lightweight schema/config helper, and separating schema input types from config resolution while preserving existing exports ([#209](https://github.com/wolfstar-project/stars-components/pull/209)). ## 2026-09-24 ### New features * **New package** — The `stars.config.*` schema and loader now live in `@wolfstar/schema`. Imports from `@wolfstar/http-framework/config` keep working unchanged. If you install `@wolfstar/cli` without `@wolfstar/http-framework`, add `@wolfstar/http-framework` yourself. Scaffolded projects are unaffected. ### Updates * **Structured diagnostics** — Config errors are now [`nostics`](https://github.com/vercel-labs/nostics) diagnostics with stable codes. `ConfigError` is removed. Catch errors with `instanceof Diagnostic` instead. See [Config errors](https://stars-components.js.org/documentation/errors/config.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.