Spraxium logoSpraxium
Volver al changelog
Spraxium 0.1.0, First Public Release
v0.1.0

Spraxium 0.1.0, First Public Release

The first public release of Spraxium. Production-ready, thoroughly tested, and open to the community.

Publicado el: 20 abr 2026

A framework that was already in production

Spraxium did not start as an open-source project. It started as an internal tool at Spacelaxy, built to solve a very specific frustration: writing the same boilerplate in every Discord bot, again and again, with no enforced structure and no safe way to share logic between commands. The answer was a module system, a dependency injection container, and a guard pipeline, all shaped around how Discord bots actually work in production, not how a tutorial says they should.

For over a year, every Spacelaxy bot ran on some version of this framework before the first commit ever hit a public repository. That means version 0.1.0 is not a prototype. It is a cleaned-up, documented snapshot of software that has already handled real traffic, real users, and real edge cases across multiple bots running simultaneously.

What ships with this release

This release delivers the complete core of the framework as a set of independent, composable packages. Each one can be used on its own or alongside the others. There is no mandatory integration between them, you bring only what you need.

  • @spraxium/core. The foundation. Provides the module system, the dependency injection container, the command and event handler registry, guard pipelines, and the full bot lifecycle. This is the package most bots will import first and the one we have tested the most extensively.

  • @spraxium/common. Shared decorators, types, and utilities that tie the rest of the system together. It is a peer dependency for most other packages and is intentionally kept minimal.

  • @spraxium/http. An HTTP server that runs in the same process as your Discord bot. Adds controllers, DTOs, validation, and a BotBridge that allows HTTP handlers to send Discord messages directly without any shared state or coupling between services.

  • @spraxium/i18n. Per-guild localization. Handles lazy-loaded message files, locale resolution per guild, and fully typed translation keys that work inside slash command handlers and embeds alike.

  • @spraxium/schedule. Cron and interval jobs integrated into the module lifecycle. Jobs start after the bot is ready and stop cleanly on shutdown. No external scheduler, no cron daemon.

  • @spraxium/signal and @spraxium/signal-client. Cross-service event delivery. The server package receives HMAC-signed payloads from any Node.js backend. The client package sends them. Events are typed end to end with no polling, no shared database, and no coupling between services.

  • @spraxium/env. Environment variable validation at startup using auto-generated schemas. If a required variable is missing or malformed, the process exits before any connection is attempted. No silent failures, no undefined reads at runtime.

  • @spraxium/cli. The spraxium command-line tool. Scaffolds new projects, generates modules, providers, commands, and guards, and runs the dev server with hot reload. The templates shipped with this release cover the most common bot patterns.

Production-ready, with honest caveats

We are confident in the stability of the core module system, the dependency injection container, guard execution order, lifecycle hooks, and the majority of the CLI generators. These components have been running inside real bots and stress-tested across many different command loads and restart cycles.

That said, this is version 0.1.0, and there are areas where the surface area is large and our coverage is thinner. Highly dynamic module configurations, certain edge cases in circular dependency resolution, and a small number of advanced HTTP routing patterns have not been tested as extensively as the core. You may encounter rough edges in those areas. If you do, please open an issue. The bug surface at this stage is exactly what public testing is for.

All features documented on the website are stable enough to ship. None of them are experimental stubs. If something is in the docs, it works.

What comes next

The roadmap is live. The short-term focus is on developer experience: better error messages when the dependency injection container cannot resolve a token, improved CLI output during development mode, and expanded test coverage across the signal packages.

Thank you for being here at version 0.1.0. Every issue report, every question, and every bot you build with this framework is what moves it forward.