Module System

One interface. Infinite extensibility. Zero coupling.

Every module implements ModuleProviderInterface — a single contract that defines schemas, metas, abilities, UI, controllers, and migrations. The ModuleRegistry boots them in dependency order. Remove a module, the rest keep working.

ModuleProviderInterface

One contract. Everything declared.

Modules don't hook into the system — they declare what they provide. The ModuleRegistry reads the contract and handles registration, boot sequencing, dependency resolution, and cron scheduling automatically.

schemas() — entity + settings schemas → auto-CRUD via UnifiedDriver
metas() — extend orders, products, users, sessions without touching core tables
abilities() — custom abilities beyond auto-derived ones from schemas
ui() — view-based UI contracts (forms, lists, settings) for headless rendering
restControllers() — custom endpoints for business logic beyond auto-CRUD
migrations() — version-based DB migrations, run in dependency order
requires() — dependency declarations (other modules or external services)
boot() — called after all registrations, safe to add hooks and filters

contracts/ModuleProvider

typescript

1interface ModuleProvider {
2  // Identity
3  id(): string;            // "enravo-sube"
4  name(): string;          // "Branch Management"
5  version(): string;       // "1.2.0"
6
7  // Data declarations
8  schemas(): Schema[];     // → auto-CRUD endpoints
9  metas(): MetaDef[];      // → entity field extensions
10  settings(): Settings;    // → singleton schema (auto)
11  abilities(): Ability[];  // → custom abilities
12
13  // UI declarations
14  ui(): ViewSchema[];      // → view schemas
15  pageSchemas(): Page[];   // → page-level contracts
16  navigation(): NavItem[]; // → headless menu items
17  manifest(): RefData;     // → reference data
18
19  // Controllers
20  restControllers(): Controller[];
21  adminControllers(): Controller[];
22
23  // Lifecycle
24  requires(): string[];    // → dependency IDs
25  migrations(): Migration[];
26  cronJobs(): CronJob[];
27  boot(): void;            // → post-registration hook
28}

Module lifecycle

From registration to serving — every module follows the same boot sequence. Dependency resolution ensures correct order.

Module discovered from registry or external hook. Provider instantiated

Resolve Dependencies

Two-pass: instantiate all, then check requires(). Unmet deps → module skipped

Boot Provider

Abilities, schemas, metas, UI, settings auto-registered. Then boot() called

Migrate

Version-based migrations run if module version > stored version

Serve

REST controllers registered on rest_api_init. Module is live

Module discovered from registry or external hook. Provider instantiated

Resolve Dependencies

Two-pass: instantiate all, then check requires(). Unmet deps → module skipped

Boot Provider

Abilities, schemas, metas, UI, settings auto-registered. Then boot() called

Migrate

Version-based migrations run if module version > stored version

Serve

REST controllers registered on rest_api_init. Module is live

How modules extend Enravo Core

Six extension points — all declarative, all auto-registered.

Schema Extension

Modules declare schemas() → UnifiedDriver generates CRUD endpoints. Two types: singletons (settings stored in options) and collections (full CRUD in custom tables). Abilities auto-derived.

Meta Extension

Modules declare metas() → fields auto-injected into entity API responses and UI schemas. Four entity types: order, product, user, session. Per-role read/write filtering via SchemaPipeline.

UI Extension

Modules declare ui() → view schemas injected into page-level contracts at specific injection points. Widget types, layout rules, and data endpoints — all declarative.

Ability Extension

Modules declare abilities() → auto-registered and synced to roles on boot. Also auto-derived from schemas and routesMeta. Format enforced: enravo/{module}/{action}.

Address Extension

Modules declare addressFields() → custom fields added to the multi-address system. Country-specific billing, shipping, or compliance fields without core changes.

Cron & Notifications

Modules declare cronJobs() → scheduled tasks auto-registered. Notification module provides OTP delivery, security alerts, email templates, and push notification channels.

What a module can do

Each module is a self-contained provider. Some have database tables, some have assets, some just add abilities. All follow the same interface.

Own Schemas

Define data models — CRUD endpoints, validation, and abilities auto-generated via UnifiedDriver.

Extend Entities

Add fields to orders, products, users, or sessions via metas — without touching core tables.

Declare UI

Define Abilities

Custom permissions auto-synced to roles. Format enforced: enravo/{module}/{action}.

Custom Endpoints

REST controllers for business logic beyond auto-generated CRUD. Admin and public routes.

Declare Dependencies

requires() ensures modules boot in the right order. Unmet dependencies → module safely skipped.

Run Migrations

Version-based database migrations. Only run when module version changes. Dependency-ordered.

Schedule Jobs

cronJobs() auto-registered. Recurring tasks managed by the platform, not the module.

Hook into Boot

boot() runs after all registrations. Safe to add filters, hooks, and event listeners.

Next: Schema Engine

See how module schemas become full-stack APIs — from field definition to auto-generated CRUD endpoints.

One contract. Everything declared.

schemas() — entity + settings schemas → auto-CRUD via UnifiedDriver

metas() — extend orders, products, users, sessions without touching core tables

abilities() — custom abilities beyond auto-derived ones from schemas

ui() — view-based UI contracts (forms, lists, settings) for headless rendering

restControllers() — custom endpoints for business logic beyond auto-CRUD

migrations() — version-based DB migrations, run in dependency order

requires() — dependency declarations (other modules or external services)

boot() — called after all registrations, safe to add hooks and filters

1interface ModuleProvider { 2 // Identity 3 id(): string; // "enravo-sube" 4 name(): string; // "Branch Management" 5 version(): string; // "1.2.0" 6 7 // Data declarations 8 schemas(): Schema[]; // → auto-CRUD endpoints 9 metas(): MetaDef[]; // → entity field extensions 10 settings(): Settings; // → singleton schema (auto) 11 abilities(): Ability[]; // → custom abilities 12 13 // UI declarations 14 ui(): ViewSchema[]; // → view schemas 15 pageSchemas(): Page[]; // → page-level contracts 16 navigation(): NavItem[]; // → headless menu items 17 manifest(): RefData; // → reference data 18 19 // Controllers 20 restControllers(): Controller[]; 21 adminControllers(): Controller[]; 22 23 // Lifecycle 24 requires(): string[]; // → dependency IDs 25 migrations(): Migration[]; 26 cronJobs(): CronJob[]; 27 boot(): void; // → post-registration hook 28}

One interface. Infinite extensibility. Zero coupling.

One contract. Everything declared.

Module lifecycle

How modules extend Enravo Core

Schema Extension

Meta Extension

UI Extension

Ability Extension

Address Extension

Cron & Notifications

What a module can do

Own Schemas

Extend Entities

Declare UI

Define Abilities

Custom Endpoints

Declare Dependencies

Run Migrations

Schedule Jobs

Hook into Boot

Next: Schema Engine

Architecture

Schema Engine

One interface. Infinite extensibility. Zero coupling.

One contract. Everything declared.

Module lifecycle

How modules extend Enravo Core

Schema Extension

Meta Extension

UI Extension

Ability Extension

Address Extension

Cron & Notifications

What a module can do

Own Schemas

Extend Entities

Declare UI

Define Abilities

Custom Endpoints

Declare Dependencies

Run Migrations

Schedule Jobs

Hook into Boot

Next: Schema Engine