Catalog

Schematic	Aliases	Generated shape
`app`	`application`	Application under `apps/`.
`library`	`lib`	Private package under `packages/`.
`class`	`cl`	Plain class.
`controller`	`co`, `route`, `router`, `routes`	Decorated HTTP controller.
`decorator`	`d`	Custom method decorator shape.
`filter`	`f`	Exception-filter-shaped class.
`gateway`	`ga`	`@WebSocketGateway()` class mounted on the native socket runtime.
`guard`	`gu`	Guard-shaped class.
`interface`	`itf`	TypeScript interface.
`interceptor`	`itc`	Interceptor-shaped class.
`middleware`	`mi`	Middleware-shaped class.
`module`	`mo`	Decorated AponiaJS module.
`pipe`	`pi`	Transformation-pipe-shaped class.
`provider`	`pr`	Injectable provider class.
`resolver`	`r`	GraphQL-resolver-shaped class.
`resource`	`res`	Module, service, transport shape, model, and optional data classes.
`service`	`s`	Injectable service class.

Controller alias spelling

The accepted controller aliases are co, route, router, and routes. The CLI help text also lists routers, but the argument parser does not accept it — that spelling fails with Unknown schematic "routers".

Default output shape

Schematic	Own directory by default	Spec generated
`controller`, `module`, `resolver`, `service`, `resource`	yes	yes, except `module`
`class`, `decorator`, `filter`, `gateway`, `guard`, `interface`, `interceptor`, `middleware`, `pipe`, `provider`	no (flat)	yes, except `decorator` and `interface`

--flat and --no-flat override the directory behavior; --spec and --no-spec override spec generation.

Runtime-aware output

These generated shapes correspond to implemented runtime concepts:

modules;
controllers with decorated route handlers, request parameters, and schemas;
services and providers registered as singleton providers;
plain classes, interfaces, and custom decorators as application-owned code;
applications and libraries as workspace file structures.

REST resources

A REST CRUD resource generates a working feature:

src/users/
├── entities/
│   └── user.entity.ts
├── users.controller.ts
├── users.module.ts
├── users.model.ts
└── users.service.ts

users.model.ts keeps each validator beside one exported validation-model class, built with Elysia's t. A same-named interface derives its fields from the validator, so a field is declared once and the controller uses the class directly:

const createUserSchema = t.Object({
  name: t.String({ minLength: 1 }),
});

@Validation(createUserSchema)
export class CreateUser {}
export interface CreateUser extends InferValidatorOutput<typeof createUserSchema> {}

@Post("/", { body: CreateUser })
create(@Body() input: CreateUser) {
  return this.usersService.create(input);
}

@Patch(":id", { params: UserParams, body: UpdateUser })
update(@Param() params: UserParams, @Body() input: UpdateUser) {
  return this.usersService.update(params.id, input);
}

Swap in any Standard Schema validator — Zod, ArkType, Valibot — by editing that one file.

WebSocket resources

A ws resource generates a provider-registered gateway instead of a controller. A CRUD WebSocket resource maps <resource>.create, .findAll, .findOne, .update, and .remove through @SubscribeMessage() and injects event data with @MessageBody(). A standalone gateway schematic is mountable as soon as it is registered as a provider:

import { WebSocketGateway } from "@aponiajs/common";

@WebSocketGateway("/events")
export class EventsGateway {}

See WebSocket gateways for the envelope and runtime behavior.

Scaffold-only output

The CLI also generates Nest-familiar shapes before the corresponding AponiaJS runtime contracts exist:

filters;
guards;
interceptors;
middleware;
pipes;
resolvers;
GraphQL and microservice resources.

These classes have conventional method names but are not discovered or invoked by the framework runtime.

Use --dry-run before generation and review every scaffold before integrating it.

Schematics