@wolfstar/prettier-config@0.1.2

Patch Changes

• #210 7f15974 - fix(deps): update all non-major dependencies Thanks @renovate!

@wolfstar/oxlint-config@0.2.1

Patch Changes

• #210 7f15974 - fix(deps): update all non-major dependencies Thanks @renovate!

@wolfstar/oxfmt-config@0.2.1

Patch Changes

• #210 7f15974 - fix(deps): update all non-major dependencies Thanks @renovate!

@wolfstar/i18next-type-generator@3.1.4

Patch Changes

• #210 7f15974 - fix(deps): update all non-major dependencies Thanks @renovate!

@wolfstar/create-http-framework@2.5.2

Patch Changes

• #210 7f15974 - fix(deps): update all non-major dependencies Thanks @renovate!

@wolfstar/shared-http-pieces@2.0.5

Patch Changes

• Updated dependencies [9b71e86, 18eda16]:
  • @wolfstar/http-framework@5.0.0

@wolfstar/http-framework@5.0.0

Major Changes

• #207 9b71e86 - Implemented experimental.enableNitro: stars dev/stars build now build the bot through
  Nitro 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 — a method on Client
    itself rather than a separate adapter module to import and wire up.
  • @wolfstar/cli: Nitro v3 is itself a Vite plugin — there is no separate nitro build step — 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 (see
    https://nitro.build/examples/import-alias), and stars prepare's generated .stars/tsconfig.json now emits the
    same ~/@/~~/@@ aliases build.tool: 'tsdown' already gets whenever experimental.enableNitro is on — a
    project's own tsconfig.json#paths/package.json imports just work under Nitro too, without a
    vite-tsconfig-paths plugin. Thanks @RedStar071!

• #205 18eda16 - Replaced the hand-rolled ConfigError (@wolfstar/http-framework/config) and CliError (@wolfstar/cli) error
  classes with nostics Diagnostics: stable, typed diagnostic codes with a
  why, an actionable fix, and a docs link, instead of ad hoc code/hint/path/file fields.

  • @wolfstar/http-framework/config no longer exports ConfigError/ConfigErrorOptions. Every stars.config.*
    validation and load failure is now built from configDiagnostics (also exported) and thrown as a nostics
Diagnostic — catch it with instanceof Diagnostic (from nostics) instead of instanceof ConfigError. The
    option path that used to live on .path is folded into the diagnostic's message; the configuration file that used
    to live on .file is now in .sources.
  • @wolfstar/cli no longer exports CliError/CliErrorOptions. Its own errors are now built from the new
    cliDiagnostics catalog (also exported) and are Diagnostic instances too. formatError renders a Diagnostic
    with nostics' own ANSI formatter; exitCodeOf maps stars.config.* diagnostic codes to exit code 2 and
    BUILD_FAILED to 3, the same as before.

  ExitCode, exitCodeOf and formatError keep their existing exports and behaviour for every other case (an
  unexpected error still renders as a crash report, a non-Error value still stringifies). Thanks @RedStar071!

@wolfstar/http-framework-test-utils@3.0.9

Patch Changes

• Updated dependencies [9b71e86, 18eda16]:
  • @wolfstar/http-framework@5.0.0

@wolfstar/cli@1.0.0

Major Changes

• #205 18eda16 - Replaced the hand-rolled ConfigError (@wolfstar/http-framework/config) and CliError (@wolfstar/cli) error
  classes with nostics Diagnostics: stable, typed diagnostic codes with a
  why, an actionable fix, and a docs link, instead of ad hoc code/hint/path/file fields.

  • @wolfstar/http-framework/config no longer exports ConfigError/ConfigErrorOptions. Every stars.config.*
    validation and load failure is now built from configDiagnostics (also exported) and thrown as a nostics
Diagnostic — catch it with instanceof Diagnostic (from nostics) instead of instanceof ConfigError. The
    option path that used to live on .path is folded into the diagnostic's message; the configuration file that used
    to live on .file is now in .sources.
  • @wolfstar/cli no longer exports CliError/CliErrorOptions. Its own errors are now built from the new
    cliDiagnostics catalog (also exported) and are Diagnostic instances too. formatError renders a Diagnostic
    with nostics' own ANSI formatter; exitCodeOf maps stars.config.* diagnostic codes to exit code 2 and
    BUILD_FAILED to 3, the same as before.

  ExitCode, exitCodeOf and formatError keep their existing exports and behaviour for every other case (an
  unexpected error still renders as a crash report, a non-Error value still stringifies). Thanks @RedStar071!

Minor Changes

• #207 9b71e86 - Implemented experimental.enableNitro: stars dev/stars build now build the bot through
  Nitro 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 — a method on Client
    itself rather than a separate adapter module to import and wire up.
  • @wolfstar/cli: Nitro v3 is itself a Vite plugin — there is no separate nitro build step — 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 (see
    https://nitro.build/examples/import-alias), and stars prepare's generated .stars/tsconfig.json now emits the
    same ~/@/~~/@@ aliases build.tool: 'tsdown' already gets whenever experimental.enableNitro is on — a
    project's own tsconfig.json#paths/package.json imports just work under Nitro too, without a
    vite-tsconfig-paths plugin. Thanks @RedStar071!

Patch Changes

• Updated dependencies [9b71e86, 18eda16]:
  • @wolfstar/http-framework@5.0.0

@wolfstar/oxlint-config@0.2.0

Minor Changes

• #202 78b70d9 - Ship the shared configs as built TypeScript modules created with defineConfig from oxfmt/oxlint instead of raw JSON files. @wolfstar/oxfmt-config now default-exports a config object to spread into oxfmt.config.ts, and @wolfstar/oxlint-config default-exports one to pass to extends in oxlint.config.ts. The index.json and .oxlintrc.json entry points are removed. Thanks @RedStar071!