Packages and versioning

Public packages

AponiaJS publishes five usable packages:

The unscoped aponiajs facade is private in the workspace and is not published. It intentionally exports nothing until it can re-export a settled framework API, so do not install it.

HTTP applications

Install:

bun add @aponiajs/common@alpha @aponiajs/platform-elysia@alpha elysia@^1.4.29

Import the authoring API and platform factory from their owning packages:

import { Controller, Get, Injectable, Module } from "@aponiajs/common";
import { AponiaFactory } from "@aponiajs/platform-elysia";

Most HTTP applications receive @aponiajs/core through the platform package.

Standalone core

Install core directly only for low-level module graph, dependency container, or platform-adapter work:

bun add @aponiajs/common@alpha @aponiajs/core@alpha

Core does not export AponiaFactory, HTTP routing, or Elysia integration.

CLI packages

Install the global CLI:

bun add --global @aponiajs/cli@alpha
aponia new my-api

Or invoke the matching project generator:

bun create aponia my-api

See the CLI reference for command behavior and runtime limitations.

Synchronized versions

All five public packages use the same release version and move to the same npm distribution tag together. The tag is derived from the version, never chosen by hand: 0.6.0-alpha.18 publishes to alpha and receives the next alias, while latest only ever holds a stable X.Y.Z release and therefore never points at an alpha. Do not combine different AponiaJS versions in one application.

The audited source baseline is 0.6.0-alpha.18. Because 0.y.z releases are initial development versions, minor releases may contain breaking API changes. Check the package registry and source release notes for the version you install instead of assuming this page describes a future release.

Release branches

Persistent branches and npm channels move forward in order:

next is an alias for the newest alpha, beta, or release candidate and has no branch. Canary versions are stamped by CI and are never promoted. The release workflow verifies that the version-derived tag matches its persistent branch.