elysia

What this skill does

# Elysia Developer Guide

This skill provides guidelines, patterns, and best practices for working with the Elysia framework in this project.

## Quick Start

For detailed development guidelines, imports, and patterns, please refer to `references/patterns.md` in this skill directory.

## Core Philosophy

- **Pattern-agnostic but feature-based** structure recommended
- **"1 Elysia instance = 1 controller"** principle
- **Strong typing** with TypeBox for runtime validation
- **Centralized error handling** and consistent responses
- **Production-ready** deployment strategies

## Structure, Routing & Controllers

### Essential Organization Patterns

- **App as controller**: Treat each `new Elysia({ prefix })` instance as the controller for that feature. Do **not** pass entire class methods directly as handlers. Instead, inline a small handler that calls service functions.
- **Feature folders**: Use a feature-based structure:
  - `src/modules/<feature>/index.ts` - Elysia controller (routes, guards, cookies)
  - `src/modules/<feature>/service.ts` - business logic (no HTTP context)
  - `src/modules/<feature>/model.ts` - schemas & types via `t` (TypeBox)
  - Keep shared utilities in `src/utils/*`.
- **Method chaining**: Prefer fluent chaining on the Elysia instance for routes, guards, plugins.
- **Plugins**: Encapsulate cross-cutting concerns in plugins via `.use()` (e.g., OpenAPI, JWT, CORS).
- **Context hygiene**: If a service needs request data, keep it in the controller and pass only the relevant fields into the service function.

### Feature Scaffolding Pattern

When scaffolding a feature, generate:

1. `model.ts` with `t.Object(...)` schemas and exported `type` aliases via `typeof schema.static`.
2. `service.ts` with pure functions (or an `abstract class` of statics when no instance state is needed).
3. `index.ts` that mounts the Elysia routes, applies `guard()` with shared validation, and returns typed responses.

## Validation, Schemas & Types

### Runtime Validation + Static Types

- Use `import { t } from 'elysia'` to define **Body**, **Query**, **Params**, **Headers**, **Cookie**, and **Response** schemas.
- Derive TS types from `typeof schema.static` and export them (e.g., `export type SignInBody = typeof signInBody.static`).
- Apply shared validation with `.guard({ ... })`. If combining guards, consider `schema: 'standalone'` to keep them independent.
- Validate **files** by content: use `fileType` (magic number) when using standard schema systems.
- Ensure **response** schemas are present for 2xx and error variants for strong end-to-end typing.

### Handler Schema Guidelines

When generating handlers:

- Include the 3rd argument schema object with `body/query/params/headers/cookie/response`.
- Don't parse body for GET/HEAD (Elysia follows HTTP spec).
- Provide examples with `t.Object`, `t.Array`, `t.Union`, `t.Literal`, file schemas, and show `guard()` for shared query/headers.

## Error Handling & Response Shape

### Centralized Error Management

- Use `.onError(({ code, error, path, request }) => { ... })` on the app to map framework and custom errors to a **uniform JSON** shape (e.g., `{ ok: false, error: { code, message, details } }`).
- Prefer `throw status(code, messageOrPayload)` for error control flow that `onError` can catch. Note: `return status(...)` won't be caught by `onError`.
- Validation errors: normalize them to a predictable JSON (array of issues) while hiding sensitive internals in production.
- Include correlation ids (e.g., `x-request-id`) and log within `onError`. Avoid leaking stack traces in production.
- For success responses, optionally wrap in `{ ok: true, data }` for uniformity.

### Error Plugin Structure

When generating code, create:

- `src/plugins/error.ts` that installs `.onError(...)`.
- Optionally `src/plugins/logging.ts` to log in `onResponse` & `onError`.

## OpenAPI, Auth & Cross-cutting

### OpenAPI

- Add `@elysiajs/openapi` plugin and expose docs route (Scalar UI).
- Keep **response** schemas accurate - OpenAPI derives from them.
- If building SDKs, ensure routes are fully typed and examples provided.

### Auth

- Use `@elysiajs/jwt` for JWT signing/verification, or integrate with your auth of choice.
- Keep auth in a plugin that decorates context with `user` after verification.
- Protect routes via `.guard({ headers: t.Object({ authorization: t.String() }) })` and verify bearer tokens before handlers.

### Cross-cutting Plugins

- Install `@elysiajs/cors` where needed.
- Consider `@elysiajs/server-timing` and `@elysiajs/opentelemetry` for observability.

When scaffolding, generate `src/plugins/openapi.ts`, `src/plugins/auth.ts`, and wire them in `src/app.ts`.

## Deploy, Performance & Docker

### Production Deployment

- **Cluster mode** for multi-core: use a small launcher (`index.ts`) that forks workers and imports `server.ts` per worker.
- Prefer building with bundlers like Vite or esbuild for production deployments.
- If compiling interferes with tracing (OpenTelemetry), avoid `--minify` or mark instrumented modules as `--external`.
- Accept `process.env.PORT` (with fallback) and bind `0.0.0.0` for PaaS.

### Docker

- Build stage: use Node.js base image with pnpm.
- Runtime: **distroless** base, copy binary, `CMD ["./server"]`.

### Deployment Scaffolding

When generating a deploy scaffold, include:

- `src/index.ts` (cluster launcher), `src/server.ts` (app), `Dockerfile` (multi-stage), and build scripts.

## Testing

### Unit Tests

- Use `vitest`.
- Import the app and use `app.handle(new Request(url, options))` to assert status/body/headers.
- For service tests, call pure functions directly.

### Test Examples to Include

- Simple GET test returning text.
- POST with `body` validation (both valid and invalid paths).
- Authenticated route example using a mocked `Authorization` header.
- Prefer small, focused tests per route and per service.

## Quick Utilities

### Common Patterns

- App context: use `.state()` and `.decorate()` to add version info, helpers, etc., then read from `{ store, getDate }`.
- WebSocket endpoints via `.ws()` for simple real-time APIs.
- Custom body parser with `.onParse()` for special content types.

## Validation Checklist

Before finishing a task involving Elysia:

- [ ] Feature structure follows `model.ts`, `service.ts`, `index.ts` pattern.
- [ ] All handlers have proper schema definitions (body/query/params/response).
- [ ] Error handling uses centralized `.onError()` plugin.
- [ ] Response schemas are defined for OpenAPI generation.
- [ ] Tests use `app.handle(new Request(...))` pattern.
- [ ] Run type checks (`pnpm run typecheck`) and tests (`pnpm run test`).

For detailed patterns and code examples, see `references/patterns.md`.