Quick Start

Scaffold and run your first EFC API in under a minute. You need Node.js 22 or later (24 recommended); MongoDB, PostgreSQL or Redis only if you choose features that use them.

Create a project

$ npx create-efc-app my-api

The interactive wizard asks:

? Project name:          my-api
? Language:              TypeScript | JavaScript
? Database:              MongoDB | PostgreSQL
? Models:                defineTable | defineModel        (PostgreSQL)
                         defineCollection | defineModel   (MongoDB)
? Task queue backend:    BullMQ | pg-boss
? Multi-core clustering? Yes
? Authentication:        http-only cookie   browsers — websites and SPAs (recommended)
                         Bearer token       mobile/desktop apps, API clients
                         None               add later with `efc add auth`
? Add features now? (space to toggle)
    ◉ Authentication
    ◯ User portal …   ◯ Admin portal …   ◯ Email client …

Every feature is a registry item — tick it now or add it later with efc add <item>. Some ask a follow-up: the Email client asks for Gmail or a custom SMTP host (see Mailer); Sign in with Google / Apple ask for their credentials.

It then writes the project, generates .env with a real JWT_SECRET, and runs npm install.

Start the dev server

$ cd my-api
$ npm run dev

npm run dev runs efc start dev: one process with hot reload. Tables and indexes are created the first time a model is used, so there's no migration to run first. The scaffolded src/api/health.ts answers at http://localhost:3000/v1/api/health — /v1/api is the default basePath.

In development, http://localhost:3000/ shows the API dashboard: every route, with its methods and documentation.

Add a route

$ efc generate route posts/[slug]
# → Created src/api/posts/[slug].ts

That's it — the file is registered as /posts/:slug the next time the server reloads. Check the result any time with efc routes.

Next

• Project Structure — what every generated file is for.
• File-Based Routing — the naming rules.
• Database — models on MongoDB and PostgreSQL.

Project Structure

Every EFC project follows the same layout. src/api/ and src/tasks/ are fixed conventions — there is no option to move them.

my-api/
├── src/
│   ├── api/                       # HTTP routes — every file is a route
│   │   ├── health.ts              # GET /health
│   │   ├── auth/
│   │   │   ├── login.ts           # POST /auth/login
│   │   │   └── logout.ts          # POST /auth/logout
│   │   └── users/
│   │       ├── index.ts           # GET /users · POST /users
│   │       └── [id].ts            # GET /users/:id · DELETE /users/:id
│   ├── tasks/                     # background jobs (scanned non-recursively)
│   │   └── SendEmail.ts           # task name: "SendEmail"
│   ├── model/                     # models
│   │   ├── User.ts
│   │   └── Role.ts                # with the RBAC option
│   ├── migrations/                # efc db migrate — run in filename order
│   ├── seeds/                     # efc db seed
│   └── index.ts                   # entry point — calls ignite()
├── efc.config.ts                  # builds the config ignite() receives
├── .env                           # secrets — gitignored
├── .env.example                   # documented template — committed
├── package.json
└── tsconfig.json

Conventions

• Every .ts / .js file in src/api/ becomes a route; its path is the URL.
• [brackets] in a file or folder name become URL parameters.
• index.ts maps to its folder's path.
• Every file directly inside src/tasks/ registers a task named after the file. Subfolders are not scanned.
• src/index.ts is what runs. efc.config.ts only takes effect because src/index.ts imports it.

Production builds

efc build prod transpiles every file under src/ into dist/src/ without bundling — routes and tasks are discovered by scanning the filesystem, so they must exist as files. efc start prod runs dist/src/index.js.

Enabling User portal or Admin portal fills src/model/ and src/api/ out considerably — see Generated Portals.

Configuration

ignite() takes one config object. It never reads efc.config.ts or .env by itself — you import the config and pass it in, so what you see is what runs.

efc.config.ts

The scaffolder generates a config that reads each environment variable explicitly:

import type { EFCConfig } from 'express-file-cluster'

const config: EFCConfig = {
  port: process.env.PORT ? Number(process.env.PORT) : undefined,
  databaseUrl: process.env.DATABASE_URL,
  jwtSecret: process.env.JWT_SECRET,
  authStrategy: 'http-only',
  tasks: { backend: 'bullmq', redisUrl: process.env.REDIS_URL },
  cache: { backend: 'redis', url: process.env.REDIS_URL },
  globalMiddlewares: [],
}

export default config

src/index.ts

import { ignite, gracefulShutdown } from 'express-file-cluster'
import config from '../efc.config.js'

ignite({ ...config, cluster: true })
  .then(gracefulShutdown)
  .catch(console.error)

Options

File-Based Routing

EFC scans src/api/ at startup and builds the route map from the file tree. No registration — add a file, get a route.

Routing rules

Take the path relative to src/api, drop the extension and a trailing /index, then convert each segment:

Every route is mounted under basePath — /v1/api unless you change it. A catch-all must be the last segment; anything else is a startup error.

Specificity

Routes register most specific first, comparing one segment at a time: static, then [id], then [[id]], then [...slug], then [[...slug]]. users/me.ts therefore always matches before users/[id].ts, regardless of file order.

Method dispatching

Export uppercase HTTP method names — GET POST PUT PATCH DELETE HEAD OPTIONS. A method the file doesn't export answers 405 Method Not Allowed with an Allow header.

export const GET    = async (req, res) => { /* ... */ }
export const PUT    = async (req, res) => { /* ... */ }
export const PATCH  = async (req, res) => { /* ... */ }
export const DELETE = async (req, res) => { /* ... */ }

Route metadata

Export a meta object to document the route in the API dashboard. It is keyed by HTTP method, so every method gets its own description and examples. All fields are optional.

export const meta = {
  GET: {
    description: 'Fetch a user by ID.',
    request: { params: { id: 'usr_01HXZ' } },
    response: {
      status: 200,
      body: { id: 'usr_01HXZ', name: 'Ada Lovelace', createdAt: '2026-01-01T00:00:00.000Z' },
    },
  },
  DELETE: {
    description: 'Delete a user by ID.',
    response: { status: 204 },
  },
}

Route Handlers

Handlers are plain Express async (req, res) => {} functions. Thrown errors and rejected promises are caught for you.

Static route

// GET /health
export const GET = async (req, res) => {
  res.json({ status: 'OK', ts: new Date().toISOString() })
}

Dynamic route

// GET /users/:id
import { HttpError } from 'express-file-cluster'
import { User } from '../../model/User.js'

export const GET = async (req, res) => {
  const user = await User.findById(req.params.id)
  if (!user) throw new HttpError(404, 'User not found')
  res.json(user)
}

Validating input

export const schema validates params, query and body with any Standard Schema validator — zod, valibot, arktype. It runs after the file's middlewares. Failures answer 400 with issues; on success the parsed output replaces the input, so coercions and defaults apply.

import { z } from 'zod'

// one schema for every method in the file…
export const schema = {
  params: z.object({ id: z.string().uuid() }),
}

// …or keyed by method
export const schema = {
  GET:   { query: z.object({ include: z.enum(['reviews', 'stock']).optional() }) },
  PATCH: { body: z.object({ price: z.number().positive() }) },
}

{
  "error": "Validation failed",
  "statusCode": 400,
  "issues": [{ "path": ["params", "id"], "message": "Invalid uuid" }]
}

OpenAPI

Since 0.11.0, generate an OpenAPI 3.1 document from the routes, request validators and metadata your app already uses.

import { ignite } from 'express-file-cluster'

await ignite({ openapi: true }) // GET /openapi.json

OpenAPI is opt-in. Validators need Standard JSON Schema support or an explicit schemaToJSONSchema adapter. Use meta.GET.openapi for response schemas, security declarations and other operation overrides. Hidden/protected GET and HEAD routes cannot be shadowed by the document endpoint.

Object query fields use bracket syntax such as ?filter[name]=Alice; array keys use tags[] so one item remains an array. Optional bodies stay optional, and equivalent optional URL variants preserve Express parameter bindings. For offline use, call generateOpenAPI('/absolute/path/to/api').

Full API reference

WebSockets

Export WS from a route file to accept WebSockets on the same HTTP server and API base path.

import type { WebSocketHandler } from 'express-file-cluster'
import { requireAuth } from 'express-file-cluster/auth'

export const middlewares = [requireAuth]
export const WS: WebSocketHandler = (socket) => {
  socket.on('message', data => socket.send(data))
}

Connect to ws://localhost:3000/v1/api/chat, or use wss:// behind TLS. Global/file middleware, cookies, authentication, named params and schema.WS handshake validation apply before upgrade. HTTP handlers can coexist in the same file.

Defaults: same-origin browser policy, 1 MiB inbound messages, 30-second heartbeat and a 10-second handshake deadline. Configure ignite({ websocket: { origins: ['https://app.example.com'] } }), or disable upgrades with websocket: false. Shutdown drains connections and destroys pending handshakes.

Full API reference

OpenTelemetry tracing

Since 0.12.0, trace HTTP requests and background tasks across BullMQ, pg-boss, retries and worker-thread handoffs.

After initializing your application's OpenTelemetry SDK and context manager, enable ignite({ tracing: true }). Select components with tracing: { http: true, tasks: true }. Tracing is off by default; your application owns sampling, exporters and SDK configuration.

W3C trace context travels separately from task payloads. Request logs include trace and span IDs. HTTP spans use route templates; task handlers start with a fresh request/auth scope. Configure tracing.shutdown to flush your SDK after HTTP and task drain.

Upgrade optional peers to BullMQ 5.79.1+ or pg-boss 12.38.0+. Read the SDK setup guide and API reference.

Middleware

Three tiers, each with a clear scope. Pick the narrowest one that does the job.

1. Global middleware

Set in the config — runs before every route.

import rateLimit from 'express-rate-limit'

const config: EFCConfig = {
  globalMiddlewares: [rateLimit({ windowMs: 60_000, max: 100 })],
}

2. Route-level middleware

Export a middlewares array; it applies to every method in the file.

import { requireAuth } from 'express-file-cluster/auth'

export const middlewares = [requireAuth('admin')]

export const GET = async (req, res) => { /* ... */ }
export const DELETE = async (req, res) => { /* ... */ }

3. Handler-level, with compose()

For a guard that applies to one method only.

import { compose } from 'express-file-cluster'

export const POST = compose(
  checkQuota,
  async (req, res) => {
    res.status(201).json(await User.create(req.body))
  },
)

Order

For one request: global middlewares → the file's middlewares → schema validation → the handler (including anything it composes).

Error Handling

Throw from any handler or middleware — EFC catches it and sends a clean JSON response.

HttpError

import { HttpError } from 'express-file-cluster'

export const GET = async (req, res) => {
  const user = await User.findById(req.params.id)
  if (!user) throw new HttpError(404, 'User not found')
  res.json(user)
}

{ "error": "User not found", "statusCode": 404 }

Any other thrown error becomes a 500 with "Internal Server Error" — the message is not leaked to the client.

Custom global handler

import { HttpError } from 'express-file-cluster'
import type { ErrorRequestHandler } from 'express'

const onError: ErrorRequestHandler = (err, req, res, _next) => {
  const status = err instanceof HttpError ? err.statusCode : 500
  res.status(status).json({
    error: status === 500 ? 'Internal Server Error' : err.message,
    requestId: req.headers['x-request-id'],
  })
}

const config: EFCConfig = { onError }

Response reference

Clustering

With cluster: true — the default when NODE_ENV=production — the primary forks one worker per CPU. All workers share the port and the operating system spreads connections across them.

Pre-Flight, per worker

Every worker boots independently, in this order:

1. Configure logging (before the primary/worker split)
2. Create Express: request context and IDs, requestTimeout, CORS, JSON, cookies
3. Connect the database and set the model engine, then the cache
4. Configure auth (when jwtSecret is set)
5. Scan and register tasks from src/tasks
6. Start the queue backend — cron schedules sync in the background
7. Scan routes from src/api
8. Mount routes
9. Listen

Self-healing

When a worker exits unexpectedly, the primary calls onWorkerCrash and forks a replacement, which runs the full Pre-Flight before taking traffic.

ignite({
  ...config,
  cluster: true,
  workers: 4, // default: CPU count
  onWorkerReady: (id) => logger.info(`Worker ${id} ready`),
  onWorkerCrash: (id, code) => alerting.send(`Worker ${id} crashed (${code})`),
})

Graceful shutdown

gracefulShutdown(server) handles SIGTERM and SIGINT. A worker stops accepting connections, lets in-flight requests and task jobs finish, then exits (forced after 10 s). The primary stops respawning and relays the signal to every worker — so docker stop and Kubernetes, which signal only PID 1, don't hang.

ignite(config).then((server) => gracefulShutdown(server, 30_000)) // 30 s drain window

In development, efc start dev runs a single process with hot reload.

Background Tasks

Define tasks in src/tasks/, enqueue them from any route and respond immediately — the job runs off the request path.

Configure a backend

tasks: { backend: 'bullmq', redisUrl: process.env.REDIS_URL } // Redis
tasks: { backend: 'pg-boss' }                                // your PostgreSQL (databaseUrl)

Define a task

The task name is the file name, case-sensitive. A default export is required.

import { defineTask } from 'express-file-cluster/tasks'

export default defineTask<{ to: string; subject: string }>(async (payload) => {
  await mailer.send(payload)
})

CPU-bound work

thread: true runs the handler in worker_threads, keeping the event loop free.

export default defineTask<{ key: string; width: number }>(
  { thread: true, retries: 5 },
  async ({ key, width }) => {
    const out = await sharp(await download(key)).resize(width).toBuffer()
    await upload(`${key}@${width}`, out)
  },
)

Enqueue

import { enqueue } from 'express-file-cluster/tasks'

export const POST = async (req, res) => {
  const user = await User.create(req.body)
  await enqueue('SendEmail', { to: user.email, subject: 'Welcome' })
  res.status(202).json({ id: user.id, queued: true })
}

enqueue rejects if no backend is configured, the task name doesn't exist, or the backend doesn't accept the job within tasks.enqueueTimeout (default 5000 ms) — it never hangs, so it's safe to answer 503.

Task options

Dead letters

$ efc tasks failed --name SendEmail   # error, attempts, payload
$ efc tasks retry --all                 # re-queue
$ efc tasks purge --all                 # delete failed jobs

Authentication

JWT auth, configured by jwtSecret and authStrategy. The scaffolder asks for the strategy and puts a generated secret in .env.

http-only cookie (recommended for browsers)

The token travels in an HttpOnly + Secure + SameSite=Strict cookie named efc_token.

import { issueToken } from 'express-file-cluster/auth'

export const POST = async (req, res) => {
  const user = await verifyCredentials(req.body)
  // http-only: sets the cookie, returns undefined. bearer: returns the token.
  const token = await issueToken(res, { sub: user.id, role: user.role })
  res.json({ message: 'Logged in', ...(token ? { token } : {}) })
}

Bearer token (mobile / desktop apps, API clients)

With authStrategy: 'bearer' the same route sends the token in the body instead of a cookie. The client keeps it in secure storage (Keychain / Keystore) and sends Authorization: Bearer <token>. Browsers — SPAs included — should stay on 'http-only': any script on the page can read a token kept in localStorage. ('localStorage' is the old name for 'bearer' and still works.)

Protecting routes

import { requireAuth, getCurrentUser } from 'express-file-cluster/auth'

export const middlewares = [requireAuth] // 401 without a valid token

export const GET = async (req, res) => {
  res.json({ me: req.user, alsoMe: getCurrentUser() })
}

getCurrentUser() returns the token payload anywhere in the request — models and helpers included.

Logging out

Role-Based Access Control

Role checks are built into requireAuth — call it with role names instead of reaching for a separate middleware.

requireAuth(...roles)

import { requireAuth } from 'express-file-cluster/auth'

// bare — authentication only
export const middlewares = [requireAuth]

// authentication + role — 403 unless payload.role is one of these
export const middlewares = [requireAuth('admin')]
export const middlewares = [requireAuth('user', 'admin')]

Generated by the scaffolder

Toggle Role-based access control in create-efc-app and every protected route it generates uses this shorthand instead of an inline user.role === 'admin' check. It also generates a Role model and — with the Admin portal — a full /admin/roles CRUD API.

Database

Two model APIs. defineModel runs unchanged on MongoDB (mongoose) and PostgreSQL (Drizzle). defineTable is PostgreSQL-native, with Prisma's query vocabulary and real relations.

The engine follows database, or the databaseUrl scheme. Install mongoose for MongoDB, or pg and drizzle-orm for PostgreSQL.

defineModel

import { defineModel, type InferRecord } from 'express-file-cluster'

export const User = defineModel('User', {
  name:  { type: 'string', required: true },
  email: { type: 'string', required: true, unique: true },
  role:  { type: 'string', enum: ['member', 'admin'], default: 'member' },
})

export type UserRecord = InferRecord<typeof User> // no interface to write

Methods

Filters $eq $ne $gt $gte $lt $lte $in $nin $exists $regex $and $or, dotted paths and array-contains behave the same on both engines; updates support $set $unset $inc $push $pull. Invalid fields throw ModelValidationError (400); a duplicate unique value is a 409.

defineTable (PostgreSQL)

import { defineTable } from 'express-file-cluster'

export const Post = defineTable('Post', {
  title:  { type: 'string', required: true },
  author: { type: 'uuid', ref: 'User', onDelete: 'cascade' }, // foreign key
  tags:   { type: 'array', of: 'uuid', ref: 'Tag' },          // many-to-many
})

const posts = await Post.findMany({
  where:   { tags: { some: { label: 'efc' } } },
  include: { author: true, tags: true }, // one SQL statement, any depth
  orderBy: { createdAt: 'desc' },
  take:    20,
})

Also findUnique, upsert (INSERT … ON CONFLICT), groupBy, aggregate, relation filters and nested writes. Full reference: defineTable ↗.

Schema sync

A model's table or collection — columns, indexes, foreign keys — is reconciled on first use (autoSync, default on). Sync adds and converts; it never drops a column or a row. Preview changes with efc db sync --dry-run, or set autoSync: false and use migrations.

Transactions

import { transaction } from 'express-file-cluster'

await transaction(async () => {
  const order = await Order.create({ customer, items })
  await Stock.updateMany({ id: { $in: ids } }, { $inc: { count: -1 } })
}) // a throw rolls everything back

Raw client

import { db } from 'express-file-cluster'
// MongoDB: a mongoose Connection · PostgreSQL: a pg Pool
const { rows } = await db.query('SELECT * FROM users WHERE id = $1', [id])

db is only available after Pre-Flight — don't touch it at module load time.

Mailer

Toggle Mailer in the scaffolder for a working nodemailer transport, wired to environment variables, and a real SendEmail task.

Choose a provider

? Email provider:
  ❯ Gmail                 smtp.gmail.com, preconfigured
    Other (custom SMTP)   you'll provide host + port

With Gmail no host or port is asked — SMTP_HOST / SMTP_PORT are set to smtp.gmail.com / 465. Other prompts for both.

Gmail needs an App Password

Google rejects your normal password over SMTP. The wizard accepts only a 16-character App Password:

The generated task

import { defineTask } from 'express-file-cluster/tasks'
import nodemailer from 'nodemailer'

const transporter = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port: Number(process.env.SMTP_PORT ?? 587),
  secure: Number(process.env.SMTP_PORT) === 465,
  auth: { user: process.env.SMTP_USER, pass: process.env.SMTP_PASS },
})

export default defineTask(async (payload) => {
  await transporter.sendMail({
    from: process.env.SMTP_FROM ?? process.env.SMTP_USER,
    to: payload.to,
    subject: payload.subject,
    html: payload.body,
  })
})

Send mail with enqueue('SendEmail', payload) — see Background Tasks. With the User portal enabled too, registration, password reset and email verification enqueue it for you.

API Dashboard

In development (NODE_ENV=development), GET / serves a live page listing every route — one card per HTTP method, with its description and request/response examples. No external tooling.

Turning it on and off

It is on by default in development and does not exist in production. Set dashboard: false to disable it in development too.

Documenting a route

The cards come from each file's meta export, keyed by method. A method without an entry still gets a card, marked undocumented.

export const meta = {
  GET: {
    description: 'Fetch a user by ID.',
    request: {
      headers: { Authorization: 'Bearer <token>' },
      params: { id: 'usr_01HXZ' },
    },
    response: {
      status: 200,
      body: { id: 'usr_01HXZ', name: 'Ada Lovelace', createdAt: '2026-01-01T00:00:00.000Z' },
    },
  },
}

Type rendering

Response bodies are shown as type names, not your sample values — examples stay readable without leaking data.

Generated Portals

The User portal and Admin portal options scaffold a large, working set of models and routes — not stubs. You pick the sub-features you want, and only what they need is generated.

Every model is real on both databases: defineModel collections on MongoDB; on PostgreSQL, defineTable models (or defineModel, if you chose it) linked by foreign keys, with relations such as user.sessions and plan.subscriptions ready for include.

Always generated

POST /auth/login, POST /auth/logout and src/model/User.ts.

User portal

Models

User, Session, Notification, File, SupportTicket, Subscription, Invoice, ApiKey

Routes

Registration, me, refresh tokens, email verification, password reset and change, 2FA, session listing; profile, avatar, settings and account deletion; notifications; file uploads; favourites and bookmarks; search; API keys; billing (plans, subscription, payment methods, invoices); support tickets.

Admin portal

Models

Admin, SupportTicket, AuditLog, Plan, FAQ, Blog, Category, Coupon

Routes

Dashboard stats; user management (suspend, activate, verify, CSV export); analytics; admin management; notification broadcast; audit, activity and security logs; system health; ticket triage; content (FAQs, blog, categories); billing (plans, coupons, subscriptions) — plus /admin/roles when RBAC is on.

Protected routes export middlewares = [requireAuth], or [requireAuth('admin')] with RBAC. A src/migrations/00000000000000_init migration creates every generated table or collection.

CLI Reference

The efc binary comes with express-file-cluster. A global efc run inside a project hands off to the project's own version.

Lifecycle

Code generation

Database

Diagnostics and tasks

Which Model API?

Three ways to define a model, one foundation: the schema format, inferred types, validation, auto-sync, transaction() and errors are shared. They differ in engine and query vocabulary.

• On PostgreSQL: defineTable — what create-efc-app generates.
• On MongoDB: defineCollection — mongoose underneath.
• Might switch engines: defineModel, inside the shared filter subset.
• Coming from Prisma: defineTable; efc import-prisma writes the models.

// defineTable
const posts = await Post.findMany({
  where: { status: 'published', views: { gte: 100 } },
  orderBy: { createdAt: 'desc' },
  take: 20,
  include: { author: true },
})

Relations

With defineTable, a top-level ref is a real foreign key, an array of refs is a many-to-many join table, and relations declares the other side.

export const User = defineTable('User', {
  email: { type: 'string', required: true, unique: true },
}, {
  relations: { posts: { hasMany: 'Post', foreignKey: 'author' } },
})

export const Post = defineTable('Post', {
  title:  { type: 'string', required: true },
  author: { type: 'uuid', ref: 'User', required: true, onDelete: 'cascade' },
  tags:   { type: 'array', of: 'uuid', ref: 'Tag' },  // many-to-many
})

Read, filter, write

// One SQL statement, any depth
const user = await User.findUnique({ where: { id }, include: { posts: { include: { tags: true } } } })

// Relation filters: some / every / none, is / isNot
const writers = await User.findMany({ where: { posts: { some: { title: { contains: 'EFC' } } } } })

// Nested writes, one transaction
await Post.create({ data: {
  title: 'Hi',
  author: { connect: { id } },
  tags: { connectOrCreate: [{ where: { label: 'news' }, create: { label: 'news' } }] },
} })

Coming from Prisma

defineTable speaks Prisma's query language on PostgreSQL — the schema in TypeScript instead of a .prisma file, and no generate step.

$ npx efc import-prisma prisma/schema.prisma
# → src/model/User.ts, Post.ts, … over the same tables and columns

Coming from mongoose

defineCollection keeps mongoose's query language with the schema as a plain object and types inferred from it. It is mongoose underneath — your data and indexes stay as they are.

export const Place = defineCollection('Place', {
  name:     { type: 'string', required: true },
  price:    { type: 'decimal128' },
  location: { type: 'geoPoint', index: '2dsphere' },
  owner:    { type: 'objectId', ref: 'User' },
})
export type Place = InferRecord<typeof Place>   // no interface to keep in step

Environment Variables

ignite() doesn't read process.env for configuration — the scaffolded efc.config.ts does, and passes the values in. NODE_ENV is the one variable the framework reads directly.

create-efc-app writes .env (gitignored, secrets filled in) and .env.example (committed, documented placeholders).

Type Inference

Models are typed from their schema literal — InferRecord<typeof M> for reads, InferCreate<typeof M> for writes. No interfaces to keep in step.

defineTable's select / include and defineCollection's pipeline() narrow result types further. Full table: docs/api-reference/types.md.

Feature Matrix

What each model API does on which engine — every row names the test that proves it against a real database, and CI fails if a cited test disappears.

The full matrix with test citations: docs/guides/feature-matrix.md.

Versioning & Support

All three packages ship together under one version, following semver.

LTS from 1.0: the current major gets everything; the previous major gets security and critical fixes for 12 months after the next one ships. Before 1.0, only the latest 0.x release gets fixes.

Node.js: active and maintenance LTS lines — tested on Node 22 and 24.

0.10.2 auth fixes: update owned login, refresh, logout, reset-password, change-password and two-factor helper files. Reset links are consumed atomically and invalidate refresh credentials. Custom-entity logout propagates revocation failures. ESM/CommonJS middleware shares auth, request context and cache state.

Generated code is yours: upgrading the package doesn't change files create-efc-app or efc add wrote. When a release fixes generated code, the changelog names the files — re-add them with efc add <item> --overwrite or apply the change by hand.