ExisJS is Now in Public Beta

Today, ExisJS is entering public beta.

Over several months of closed testing, one thing became clear: the core ideas file-system routing, typed plugins, zero-config databases were holding up. But as we started planning toward a stable 1.0.0, we realized we needed a clean slate first.

As part of that shift, we're resetting the package version to 0.1.0 and moving everything under the official @exisjs npm organization.

This gives us room to build in public, take in feedback, and make real architectural changes without the weight of a stable 1.0.0 API to maintain just yet. If you're starting a new project today, the beta is safe to build on just keep an eye on the changelog when you upgrade.

The Move to NPM Scopes

Until now, ExisJS was published under my personal npm account as a single package. That worked fine early on, but it came with real limits. npm's typo-squatting protections make short names like exis nearly impossible to register cleanly, and a single package doesn't scale well once an ecosystem starts to grow around it.

From here on, ExisJS is organized as a proper scoped ecosystem:

• @exisjs/core : the backend framework and router itself: request pipeline, DI container, and core HTTP handling.
• @exisjs/create : the CLI for scaffolding new projects. We rebuilt it to get you from a blank folder to a running server in under a minute.
• @exisjs/client : a fully type-safe RPC client, so your React, Vue, or Svelte frontend can call backend routes with full autocomplete and no code-generation step.

Publishing under an organization also means fewer naming conflicts down the line, and it sets us up to bring on more maintainers and plugin authors as the project grows.

Roadmap to 1.0.0

Public beta is the starting point, not the finish line. Between now and 1.0.0, we're focused on three things:

1. Stabilizing the request pipeline. We're benchmarking cold-start times and optimizing the internal routing tree so ExisJS holds up under real production load, not just synthetic benchmarks.
2. Rounding out zero-config integrations. Postgres, Redis, and MongoDB support is solid today. Before 1.0, we want native S3 and Resend adapters too, so common infrastructure doesn't mean hand-rolled boilerplate.
3. Locking in the plugin API. A few of you have already started building against onRequest and onResponse. We'll freeze those lifecycle hooks soon so plugin authors have a stable foundation to build on.

If you're considering building an official plugin, reach out I'd rather work closely with early plugin authors while the API can still bend, than lock something in and find out later it doesn't fit.

Everything here is happening in the open. If you want to contribute, file an issue, or just talk through TypeScript backend patterns, the repo is open: github.com/v25group/exisjs.