What is Heximon?

Heximon is a TypeScript backend framework for building APIs, SaaS backends, and internal services. You write plain classes — a controller, a repository, a module that lists them — and the compiler wires them together before your app ever runs.

import type { Controller, Get } from "@heximon/http";
import { type User, UsersRepository } from "./users.repository";

export class UsersController implements Controller<"/users"> {
  constructor(private readonly users: UsersRepository) {}

  public async list(_action: Get<"/">): Promise<User[]> {
    return this.users.list();
  }

  public async get(action: Get<"/:id">): Promise<User | { error: string }> {
    const user = await this.users.findById(action.request.pathParams.id);
    return user ?? { error: "User not found" };
  }
}

There's no decorator to add. UsersRepository is a constructor parameter; the compiler reads that signature, the module it's listed in, and generates the code that constructs both.

Why Heximon

The pain of a hand-wired backend isn't day one — it's day ninety. Registration lists drift from the classes they list. A client hand-copies the shape of a response and quietly falls out of sync with the handler that returns it. A DI container that resolves dependencies at runtime turns a typo into a 2 a.m. stack trace instead of a compile error.

Heximon's bet is that this is the same problem Vite solved for frontends: resolve the structure ahead of time instead of re-deriving it on every boot. A compiler reads your module's config and your classes' constructor signatures, and emits the plain JavaScript that builds your object graph — so the mistakes that used to surface at 2 a.m. now surface in your editor, on the exact line that's wrong: a missing provider, a broken import, an unmet dependency between modules.

And if you declare a capability whose compiler plugin isn't installed, the build fails with the fix named, not a runtime undefined.

Most apps use three concepts — a module, a controller, a provider. The other 40+ packages are opt-in, one config line each.

What it costs

Being direct about the trade so you can decide with real information:

• A Vite build step. If you already run Vite, Vitest, or a Vite-powered framework, this is one more plugin in a config you already own. If you don't, it's a build step to add — small, but real.
• ESM-only, strict TypeScript. No CommonJS, no loose tsconfig. If your codebase is still on CommonJS, this is a migration, not a config flag.
• A generated .heximon/ directory. The compiler's output — you .gitignore it (the starter already does); the first compile adds the generated-directory include entry to your tsconfig.json for you, so its compile verdicts surface back in your editor.

What it doesn't cost

• No runtime container. There's nothing resolving dependencies while your app is handling requests — dispatch is plain generated JavaScript you can open and read, the same code you'd have written by hand.
• The contract package is frontend-safe. @heximon/contract has near-zero dependencies and no server import, so a typed API client can ship in a browser bundle.
• Drizzle schemas are stock Drizzle. Nothing about your database schema is Heximon-specific — it's the same drizzle-kit you already know.
• Leaving is cheap. Your classes are plain TypeScript with constructor parameters. Strip the module config and the framework imports, and what's left is code that still makes sense.

Isn't a compiler exotic?

Look at what it actually reads: a handful of source files — a provider, a controller, a module, a schema, a contract — and one heximon.config.ts line. The output is a fetch handler built from new UsersController(new UsersRepository()) — code you could have written yourself. The Quick Start walks all five files it takes to get there; nothing about the generated output is hidden from you.

When to use it — and when not to

Reach for Heximon when:

• You're building an API that's going to live long enough to grow past its first shape.
• You want end-to-end types between server and client without hand-maintaining a second copy.
• You want structure — modules, boundaries, a DI graph — without a container doing work at runtime.
• You're deploying somewhere reflection can't follow you, like an edge runtime.

Skip it when:

• You're writing a one-file script — the module/controller split is overhead you don't need yet.
• You can't move to ESM — Heximon doesn't support CommonJS.
• You can't add a build step to your workflow — a lightweight router with hand-wired classes (Hono and your own composition root, for instance) is a legitimate, simpler choice here.

Find your next page

See Where to go next for the full map.

How it works

At build time, the compiler reads each module's config and the constructor signatures of the classes it declares, then emits plain JavaScript wiring that constructs everything directly — no reflection, no container resolving anything while your app runs. See Compiler for how the graph is built.

Next steps

• Quick Start — build a three-file HTTP app and serve it in minutes.
• Installation — add Heximon to a project by hand, or scaffold one.
• Examples — the tiered example set: a progressive learning ladder, the event-ticketing flagship, and thematic gap apps.