Makes the public module-development package set usable from a module repository outside the monorepo. Nothing is published. - Curated @ekklesia/module-sdk: an explicit author API, no contracts barrel, no identity/authorization internals, no Drizzle and no legacy ModuleDatabase type. defineModuleRuntime returns the SDK's own named interfaces so a module's emitted declarations never reach into @ekklesia/contracts. defineModuleSchema is gone; createModuleTable and defineModuleSchemaMetadata live in @ekklesia/module-database. - Drizzle: no longer a dependency of module-sdk or contracts. Core keeps the legacy Drizzle schema validator (moved to core/src/modules) and its legacy runtime support; drizzle-orm is an optional peer only. - React is a peer (plus devDependency) of @ekklesia/ui; the boundary checker allows exactly that consumer-selected peer. - @ekklesia/typescript-config is publishable; module-ui-host is private. Every public package carries "ekklesia.distribution": "module-development" and no monorepo-root prepack. - module-pack reads the Node.js range from the module's own engines.node and recognizes Ekklesia packages by name plus that marker, so registry-installed packages are incorporated, SDK-compatibility checked, and never credited as third-party. - scripts/pack-public-packages.ts (pnpm packages:pack) rebuilds, packs and inspects the nine public tarballs; scripts/test-standalone-module.sh (pnpm test:standalone-module, new CI job) installs them into a fixture module outside the repository and proves it typechecks, builds, packages, and verifies. - Public-package boundary tests and module-development docs. Co-Authored-By: Claude Opus 5.5 <[email protected]>
Ekklesia module template
This is the smallest supported Ekklesia module product. It proves the static manifest,
compiled runtime and schema entrypoints, capability registration, a module-owned Drizzle table, a
generated module-owned migration, logical storage-bucket declarations, and one permissioned HTTP
route (GET /records, declared in register) that reads that table through
@ekklesia/module-database/drizzle over the platform-provided ABI-v1 executor. Drizzle stays a
module-side implementation detail; Core receives SQL and bound values, never the module's ORM
objects, a raw pg client, or connection configuration. Migration execution and storage provisioning
are intentionally not included.
It also ships two independently optional React roles: a primary/management UI at src/ui/index.tsx
and a full-viewport display at src/display/index.tsx. One invocation of pnpm build compiles each
declared role to the exact artifact in entrypoints.ui and entrypoints.display.artifact
(ADR 0023). Both default-export
the same role-neutral defineModuleUi({ id, version, mount }) ABI and receive the same
ModuleUiHostContext; there is deliberately no mode flag. The manifest entrypoint and the host route
choose the role.
Either role can be omitted independently. To remove only the display example, delete src/display/
and entrypoints.display (and remove example.display.view if nothing else uses it). To keep the
module backend-only, also delete src/ui/, tsconfig.ui.json, tsconfig.ui-test.json,
tests/module-ui.test.ts, the ui entrypoint, and the React/module-UI dependencies. The builder
succeeds with an empty artifact list when neither role is declared.
tests/module-ui.test.ts builds both artifacts from source, validates them with
parseModuleUiExport, mounts each into a real DOM, and unmounts it. Ekklesia mounts the primary UI
inside its Dashboard shell and serves the display without Dashboard chrome at the stable
/display/example page. See
Declaring UI entrypoints.
To create a module inside this repository:
- Copy this directory to
modules/<module-id>. - Rename the package in
package.jsonand removeprivatewhen it is ready for publication. - Update the ID, name, version, namespaces, compatibility ranges, and bucket requests in
ekklesia.module.json. - Keep the manifest capability versions and dependency ranges aligned with the contracts the module actually implements and consumes.
- Replace
src/server/index.tswith backend behavior only. ItsdefineModuleRuntimeID and version must match the manifest; do not duplicate the rest of the manifest in TypeScript. Declare HTTP routes only inregister, against a permission the manifest already declares;start,stop, and every route handler — neverregister— receivecontext.services.database, a typed Module Database ABI-v1 executor. Adapt it withmoduleDrizzle; do not pass ORM objects to Core. - Replace the pure Drizzle declarations in
src/schema/tables.tsand keep its table prefix aligned with the module ID. KeepmoduleDrizzleSchemaMetadatainsrc/schema/index.tsaligned too; it exports plain ownership and foreign-key metadata, never ORM objects. Never import another module's schema. - Update
drizzle.config.ts, generate forward migrations withpnpm migration:generate --name=lowercase_namefrom the module directory, and review the SQL. Keep each generated tag indrizzle/meta/_ekklesia.json, classify it asnoneorapproval-required, and change that file'smoduleIdwhen renaming the template. - Run
pnpm install,pnpm build,pnpm modules:validate,pnpm migrations:validate, andpnpm verifyfrom the repository root. The declared production entrypoint is the compileddist/server/index.js, not source TypeScript; the schema entrypoint is likewise compiled todist/schema/index.js.
That modules/<module-id> directory is where a module is developed. An installation never runs
it from there: Ekklesia's image contains no modules, and an installation installs a self-contained
copy of the module into its module storage
(An installed module is self-contained,
ADR 0048). Copying dist/ alone is not enough, because the compiled server code imports the Module
SDK and Drizzle by name. After building, package the module with the canonical packager, which
bundles the backend into one deterministic Ekklesia Module Package (ADR 0049):
pnpm modules:pack --module templates/module --target any --out <directory> \
--license-file LICENSE \
--source-revision "$(git rev-parse HEAD)"
The module owns its feature screens and display renderer. Do not add platform navigation, the
containing shell, global theme, authentication screens, or top-level routing; those belong to
surfaces and Core. A module UI asks its host for relative API paths and realtime state, and never
hardcodes Ekklesia routes. The display permission is enforced by the host before it serves the page
or descriptor; context.permissions remains a presentation-only hint.
Keep imports side-effect-free, register capabilities in register, acquire resources in start,
and release them in stop. Construct Drizzle only through the module-side ABI adapter; never read
DATABASE_URL or reach for a raw pg client. context.services.database is the only supported
executor for this module's own tables, and it is never available during register.
The migration directory uses the pinned stable Drizzle Kit 0.31.10 PostgreSQL journal and
snapshot format. Migrations are forward-only and may modify only this module's objects. Offline
validation treats SQL as opaque bytes, calculates SHA-256 from the exact contents, and never opens a
database or executes SQL. Destructive declarations are review metadata, not automatic SQL
classification or approval.
License
The template's package.json declares "license": "AGPL-3.0-or-later", the license of Ekklesia
and of official Ekklesia modules (see the repository README and
LICENSE). A module started from the template begins with that declaration; an
official Ekklesia module keeps it. The packaging command explicitly supplies the repository's
canonical LICENSE, avoiding a duplicate file in this nested template. Its exact bytes become the
package-root LICENSE, while ekklesia.package.json.license receives the source declaration.
Standalone modules should keep their own license file and pass its path explicitly. The packager
does not infer or download license material, and THIRD_PARTY_NOTICES remains only for bundled
third-party dependencies.