@constructive-io/errors

@constructive-io/errors

Canonical Constructive error system. Zero runtime dependencies — usable by any service or client without pulling in pgpm.

• Registry — the single source of truth mapping each stable code to its classification (public vs internal), HTTP hint, and default message.
• parse(anyError) — normalize an error from any source (a ConstructiveError, a node-postgres DatabaseError, a GraphQL error or { errors: [...] } wrapper, a plain Error, or a string) into a canonical { code, context, class, known }.
• format(code, context, locale) — render a localized, interpolated message. {{var}} placeholders + registerable per-locale catalogs (i18n).
• errors.* factory — type-safe throwable builders derived from the registry, e.g. throw errors.MODULE_NOT_FOUND({ name }).
• classify(code) — public or internal; unknown codes are internal (fail safe) so transports never leak unregistered errors.
• httpStatusFor(code) — the canonical code → HTTP status mapping, so no transport keeps its own table. Unregistered codes answer 500 and are reported, never silently.

import { parse, format, errors, classify } from '@constructive-io/errors';

// Normalize a DB error surfaced through GraphQL
const parsed = parse(graphqlError);
if (parsed.class === 'public') {
  showUser(format(parsed.code!, parsed.context, locale));
}

// Throw a structured error
throw errors.ACCOUNT_EXISTS();

Design notes

• The machine code is deliberately separate from user-facing copy so codes are stable and messages are localizable.
• parse() recovers structure from the code's precedence: structured DETAIL JSON → GraphQL extensions.code → a leading ALL_CAPS token in the message (legacy DB RAISE, incl. CODE (arg, arg) positional args) → native SQLSTATE constraint mapping.
• The registry has two layers, merged at lookup time (curated wins):
  • Generated (src/generated/registry.generated.ts) — every code raised via EXCEPTION/THROW across constructive-db (deploy sources + generated output), each with a public/internal class, HTTP hint, and default message.
  • Curated (src/registry.ts) — refined, typed-context entries for the codes that matter most (public auth/limit copy, native PostgreSQL constraint codes, pgpm CLI codes). These override the generated entries.
• Unregistered codes still parse() and are classified internal (masked).

HTTP status

Every registry entry carries http, so an HTTP surface never needs its own code → status table: toError(err).http, or httpStatusFor(code) when all you have is a code.

import { httpStatusFor, setUnmappedStatusReporter, toError } from '@constructive-io/errors';

setUnmappedStatusReporter(code => log.warn({ code }, 'error code has no HTTP status'));

const err = toError(caught);
res.status(err.http).json(err.toExtensions());

httpStatusFor('ACCOUNT_DISABLED'); // { status: 403, mapped: true }
httpStatusFor('BRAND_NEW_CODE');   // { status: 500, mapped: false } + one report

mapped: false is the one case where a 500 does not mean "the server broke" — it means the code never reached the registry. That is the failure mode this exists to make loud: a refusal that is plainly a 403 or a 409 answering 500 looks like a crash, and the codes most likely to be missing are the newest ones. When a constructive-db release adds codes, refresh the registry (below); __tests__/registry-sync.test.ts fails if the snapshot and the generated registry disagree.

Regenerating the full registry

The generated layer is produced from a committed audit snapshot:

# 1. re-audit constructive-db (refreshes scripts/db-error-inventory.json)
CONSTRUCTIVE_DB_DIR=~/repos/constructive-db python3 scripts/audit-db-errors.py
# 2. regenerate src/generated/registry.generated.ts from the snapshot
python3 scripts/generate-registry.py

audit-db-errors.py scans every EXCEPTION/THROW across constructive-db deploy sources and generated output and writes scripts/db-error-inventory.json (the committed audit snapshot). It also captures the authoritative public/internal class from each canonical errors.raise_error('CODE', context, 'class') call — the database is the source of truth for classification, so an explicit class is trusted directly; codes without one (e.g. single-arg calls relying on the helper default, or legacy RAISE EXCEPTION) fall back to a name-based heuristic. generate-registry.py reads that snapshot and, when a constructive-io/dashboard checkout is found (via DASHBOARD_DIR or a sibling ../dashboard), seeds public copy from its error catalogs. Re-run both whenever constructive-db error codes change. Never hand-edit the generated file.

Education and Tutorials

• 🚀 Quickstart: Getting Up and Running Get started with modular databases in minutes. Install prerequisites and deploy your first module.

• 📦 Modular PostgreSQL Development with Database Packages Learn to organize PostgreSQL projects with pgpm workspaces and reusable database modules.

• ✏️ Authoring Database Changes Master the workflow for adding, organizing, and managing database changes with pgpm.

• 🧪 End-to-End PostgreSQL Testing with TypeScript Master end-to-end PostgreSQL testing with ephemeral databases, RLS testing, and CI/CD automation.

• ⚡ Supabase Testing Use TypeScript-first tools to test Supabase projects with realistic RLS, policies, and auth contexts.

• 💧 Drizzle ORM Testing Run full-stack tests with Drizzle ORM, including database setup, teardown, and RLS enforcement.

• 🔧 Troubleshooting Common issues and solutions for pgpm, PostgreSQL, and testing.

Related Constructive Tooling

📦 Package Management

• pgpm: 🖥️ PostgreSQL Package Manager for modular Postgres development. Works with database workspaces, scaffolding, migrations, seeding, and installing database packages.

🧪 Testing

• pgsql-test: 📊 Isolated testing environments with per-test transaction rollbacks—ideal for integration tests, complex migrations, and RLS simulation.
• pglite-test: 🪶 Drop-in pgsql-test replacement backed by PGlite — in-process Postgres, no server required, instance-per-suite isolation.
• pgsql-seed: 🌱 PostgreSQL seeding utilities for CSV, JSON, SQL data loading, and pgpm deployment.
• supabase-test: 🧪 Supabase-native test harness preconfigured for the local Supabase stack—per-test rollbacks, JWT/role context helpers, and CI/GitHub Actions ready.
• graphile-test: 🔐 Authentication mocking for Graphile-focused test helpers and emulating row-level security contexts.
• pg-query-context: 🔒 Session context injection to add session-local context (e.g., SET LOCAL) into queries—ideal for setting role, jwt.claims, and other session settings.

🧠 Parsing & AST

• pgsql-parser: 🔄 SQL conversion engine that interprets and converts PostgreSQL syntax.
• libpg-query-node: 🌉 Node.js bindings for libpg_query, converting SQL into parse trees.
• pg-proto-parser: 📦 Protobuf parser for parsing PostgreSQL Protocol Buffers definitions to generate TypeScript interfaces, utility functions, and JSON mappings for enums.
• @pgsql/enums: 🏷️ TypeScript enums for PostgreSQL AST for safe and ergonomic parsing logic.
• @pgsql/types: 📝 Type definitions for PostgreSQL AST nodes in TypeScript.
• @pgsql/utils: 🛠️ AST utilities for constructing and transforming PostgreSQL syntax trees.

📚 Documentation & Skills

• constructive-skills: 📖 Platform documentation and AI agent skills — feature catalog, blueprint reference, SDK guides (i18n, billing, limits, events, uploads, security, entities, search, AI), and deployment guides.

Install skills for AI coding agents:

# All platform skills (security, blueprints, codegen, billing, etc.)
npx skills add constructive-io/constructive-skills

# Individual repo skills (pgpm, testing, CLI, search, etc.)
npx skills add https://github.com/constructive-io/constructive --skill pgpm
npx skills add https://github.com/constructive-io/constructive --skill constructive-testing

Credits

🛠 Built by the Constructive team — creators of modular Postgres tooling for secure, composable backends. If you like our work, contribute on GitHub.

Disclaimer

AS DESCRIBED IN THE LICENSES, THE SOFTWARE IS PROVIDED "AS IS", AT YOUR OWN RISK, AND WITHOUT WARRANTIES OF ANY KIND.

No developer or entity involved in creating this software will be liable for any claims or damages whatsoever associated with your use, inability to use, or your interaction with other users of the code, including any direct, indirect, incidental, special, exemplary, punitive or consequential damages, or loss of profits, cryptocurrencies, tokens, or anything else of value.