feat: build Signage on its own from the published Ekklesia 0.2.0 packages #11

Merged

Zayin_Admin merged 1 commits from feat/standalone-build into main 2026-10-09 02:18:39 +00:00

Conversation 1 Commits 1 Files Changed 16

+2888 -4731

ekklesia-bot commented 2026-10-09 01:53:31 +00:00

Member

Copy Link

Copy Source

Ekklesia_Signage now builds on its own. A clean clone installs with pnpm install --frozen-lockfile and runs pnpm lint, typecheck, test, build and validate. The @ekklesia/* packages come from Ekklesia's public registry: no Ekklesia checkout, no workspace:*, no token. This is PR 2 of the Signage migration: dependencies and build only. Behaviour, schema and version (0.1.2) are unchanged.

Changes

• Dependencies (ADR 0053).

  • workspace:* → ^0.2.0 for module-sdk, module-database, module-ui-sdk, ui and design-tokens (dependencies), and for module-ui-build and typescript-config (devDependencies).
  • @ekklesia/module-pack is added as a devDependency pinned exactly to 0.2.0. Nothing invokes it yet.
  • No @ekklesia/contracts dependency.
  • drizzle-orm stays a direct dependency; it satisfies the adapter's optional peer.

• .npmrc: @ekklesia:registry=https://git.riverofglorymn.org/api/packages/River_of_Glory_Church/npm/. No credential, because reading needs none (ADR 0054).

• pnpm-workspace.yaml holds this repository's pnpm settings only, and doesn't reference Ekklesia:

  • allowBuilds: esbuild: true, as the platform's standalone fixture does.
  • Exact-version minimumReleaseAgeExclude entries for the nine 0.2.0 packages in the lockfile. pnpm 11 holds back packages younger than its minimum release age, and refuses a lockfile that names one, and this train was published today. Everything else keeps the policy.
  • The platform's narrowly scoped override for GHSA-67mh-4wv8-2f99 (esbuild 0.18.20 via drizzle-kit). Signage inherited it while building inside Ekklesia's workspace; without it, going standalone would bring the advisory back.

• Node and pnpm: engines.node ">=24.11.0 <25" and packageManager [email protected], both exactly as in Ekklesia 0.2.0 (module-pack requires engines.node). .node-version is 24.18.0, as in Ekklesia, and CI uses it.

• biome.json: inside the workspace, biome lint used the platform root's config. Signage now carries the same config, so lint rules are unchanged; it also excludes .pnpm-store/, which pnpm creates at the checkout root in Gitea CI.

• pnpm-lock.yaml: Signage's own lockfile: registry tarball URLs with sha512 integrity, and no workspace, file: or link: entries or local paths.

• Scripts: prepack is now pnpm run build, replacing the workspace-root turbo call. New pnpm validate (scripts/validate-module.mjs) checks the built package and its migrations using only the published SDK parsers:

  • the manifest, and that its identity matches package.json;
  • that every entrypoint exists in dist;
  • that the built runtime's id, version and database ABI match the manifest;
  • that the built schema entrypoint exports only plain metadata, with namespaced tables and module-internal foreign keys;
  • that the installed SDK satisfies compatibility.moduleSdk;
  • that the migration journal and policy parse and agree, and every migration's SQL is present.

  I checked that it fails on a stale ^0.1.0 range and on a missing migration SQL file.

• Deleted: ci/assemble.sh, ci/platform.env, ci/pnpm-lock.yaml, ci/update-lock.sh.

• CI: lint, typecheck, test and build each run checkout → setup-node (.node-version) → Corepack → pnpm install --frozen-lockfile → their command. lint also runs ci/check-cleanup.sh, and build also runs pnpm validate. No job clones Ekklesia.

• Integration job: still if: false. Its explanation now says it returns when Signage is built as a canonical linux-x64-glibc Module Package and installed into Ekklesia's generic image. Its first step is now an explicit failing placeholder instead of a call to the deleted assembly script, and ci/integration.sh's header says it isn't run.

• Docs: the README's development section now covers cloning and building Signage with no Ekklesia knowledge: Corepack, pnpm install --frozen-lockfile, the public registry with no token, the Node requirement, the commands, and what pnpm validate can't check.

Not standalone-checkable (named, not worked around)

Core's own pnpm modules:validate and pnpm migrations:validate aren't published packages. pnpm validate covers what the published parsers can check. What only an Ekklesia installation can check:

• platform-installation compatibility;
• other installed modules' capabilities and dependencies;
• migration checksums against applied history.

The packager and the platform verifier re-check everything in PR 3.

Verification

• This checkout: frozen install, lint, typecheck, test (22 files, 261 tests), build, pnpm validate (20 checks) and ci/check-cleanup.sh all pass.
• Clean-clone proof, run twice from two unrelated temporary paths. Each run cloned this commit anonymously over HTTPS, with an isolated empty HOME (no user .npmrc, no token, no pnpm config) and an empty pnpm store. In both runs:
  • no Ekklesia checkout or workspace in any parent directory;
  • frozen install, lint, typecheck, test (261), build and validate all pass;
  • no workspace:, file: or link: entries and no local path in package.json or pnpm-lock.yaml;
  • each of the nine @ekklesia packages was re-downloaded anonymously from the registry; its sha512 equals the lockfile's integrity, and the installed files are byte-identical to the tarball;
  • @ekklesia/module-pack is exactly 0.2.0 in both package.json and the lockfile;
  • pnpm store status reports only esbuild, whose allowed install script rewrites its own binary, and no @ekklesia package.
  • The two builds' dist/ outputs are byte-identical (148 files) and contain no local paths.

Found on the way (not changed here)

pnpm audit reports advisories in versions Signage already pinned on main, unchanged by this PR:

• sharp 0.35.4: high, GHSA-wq5f-xc86-pv6w, librsvg;
• happy-dom 20.0.11: high, test-only;
• vitest 4.1.10: moderate, test-only.

The sharp fix (0.35.5) needs @img/[email protected], but [email protected] only carries the reviewed license supplement for libvips 1.3.3. Native packaging with the fixed sharp will therefore likely need a new reviewed supplement in an Ekklesia release, which PR 3 should plan for.

Not in this PR

• linux-x64-glibc Module Package creation, native sharp packaging, a license field and LICENSE file (ADR 0051), and re-enabling the integration job: PR 3.

🤖 Generated with Claude Code

Ekklesia_Signage now builds on its own. A clean clone installs with `pnpm install --frozen-lockfile` and runs `pnpm lint`, `typecheck`, `test`, `build` and `validate`. The `@ekklesia/*` packages come from Ekklesia's public registry: no Ekklesia checkout, no `workspace:*`, no token. This is PR 2 of the Signage migration: dependencies and build only. Behaviour, schema and version (0.1.2) are unchanged. ## Changes - **Dependencies (ADR 0053).** - `workspace:*` → `^0.2.0` for `module-sdk`, `module-database`, `module-ui-sdk`, `ui` and `design-tokens` (dependencies), and for `module-ui-build` and `typescript-config` (devDependencies). - **`@ekklesia/module-pack` is added as a devDependency pinned exactly to `0.2.0`.** Nothing invokes it yet. - No `@ekklesia/contracts` dependency. - `drizzle-orm` stays a direct dependency; it satisfies the adapter's optional peer. - **`.npmrc`:** `@ekklesia:registry=https://git.riverofglorymn.org/api/packages/River_of_Glory_Church/npm/`. No credential, because reading needs none (ADR 0054). - **`pnpm-workspace.yaml`** holds this repository's pnpm settings only, and doesn't reference Ekklesia: - `allowBuilds: esbuild: true`, as the platform's standalone fixture does. - Exact-version `minimumReleaseAgeExclude` entries for the nine 0.2.0 packages in the lockfile. pnpm 11 holds back packages younger than its minimum release age, and refuses a lockfile that names one, and this train was published today. Everything else keeps the policy. - The platform's narrowly scoped override for **GHSA-67mh-4wv8-2f99** (esbuild 0.18.20 via `drizzle-kit`). Signage inherited it while building inside Ekklesia's workspace; without it, going standalone would bring the advisory back. - **Node and pnpm:** `engines.node` `">=24.11.0 <25"` and `packageManager` `[email protected]`, both exactly as in Ekklesia 0.2.0 (module-pack requires `engines.node`). `.node-version` is 24.18.0, as in Ekklesia, and CI uses it. - **`biome.json`:** inside the workspace, `biome lint` used the platform root's config. Signage now carries the same config, so lint rules are unchanged; it also excludes `.pnpm-store/`, which pnpm creates at the checkout root in Gitea CI. - **`pnpm-lock.yaml`:** Signage's own lockfile: registry tarball URLs with sha512 integrity, and no workspace, `file:` or `link:` entries or local paths. - **Scripts:** `prepack` is now `pnpm run build`, replacing the workspace-root turbo call. New **`pnpm validate`** (`scripts/validate-module.mjs`) checks the built package and its migrations using only the published SDK parsers: - the manifest, and that its identity matches `package.json`; - that every entrypoint exists in `dist`; - that the built runtime's id, version and database ABI match the manifest; - that the built schema entrypoint exports only plain metadata, with namespaced tables and module-internal foreign keys; - that the installed SDK satisfies `compatibility.moduleSdk`; - that the migration journal and policy parse and agree, and every migration's SQL is present. I checked that it fails on a stale `^0.1.0` range and on a missing migration SQL file. - **Deleted:** `ci/assemble.sh`, `ci/platform.env`, `ci/pnpm-lock.yaml`, `ci/update-lock.sh`. - **CI:** `lint`, `typecheck`, `test` and `build` each run checkout → setup-node (`.node-version`) → Corepack → `pnpm install --frozen-lockfile` → their command. `lint` also runs `ci/check-cleanup.sh`, and `build` also runs `pnpm validate`. No job clones Ekklesia. - **Integration job:** still `if: false`. Its explanation now says it returns when Signage is built as a canonical linux-x64-glibc Module Package and installed into Ekklesia's generic image. Its first step is now an explicit failing placeholder instead of a call to the deleted assembly script, and `ci/integration.sh`'s header says it isn't run. - **Docs:** the README's development section now covers cloning and building Signage with no Ekklesia knowledge: Corepack, `pnpm install --frozen-lockfile`, the public registry with no token, the Node requirement, the commands, and what `pnpm validate` can't check. ## Not standalone-checkable (named, not worked around) Core's own `pnpm modules:validate` and `pnpm migrations:validate` aren't published packages. `pnpm validate` covers what the published parsers can check. What only an Ekklesia installation can check: - platform-installation compatibility; - other installed modules' capabilities and dependencies; - migration checksums against applied history. The packager and the platform verifier re-check everything in PR 3. ## Verification - **This checkout:** frozen install, lint, typecheck, test (22 files, 261 tests), build, `pnpm validate` (20 checks) and `ci/check-cleanup.sh` all pass. - **Clean-clone proof**, run twice from two unrelated temporary paths. Each run cloned this commit anonymously over HTTPS, with an isolated empty `HOME` (no user `.npmrc`, no token, no pnpm config) and an empty pnpm store. In both runs: - no Ekklesia checkout or workspace in any parent directory; - frozen install, lint, typecheck, test (261), build and validate all pass; - no `workspace:`, `file:` or `link:` entries and no local path in `package.json` or `pnpm-lock.yaml`; - each of the nine `@ekklesia` packages was re-downloaded anonymously from the registry; its sha512 equals the lockfile's integrity, and the installed files are byte-identical to the tarball; - `@ekklesia/module-pack` is exactly 0.2.0 in both `package.json` and the lockfile; - `pnpm store status` reports only esbuild, whose allowed install script rewrites its own binary, and no `@ekklesia` package. - The two builds' `dist/` outputs are byte-identical (148 files) and contain no local paths. ## Found on the way (not changed here) `pnpm audit` reports advisories in versions Signage already pinned on main, unchanged by this PR: - `sharp` 0.35.4: **high**, GHSA-wq5f-xc86-pv6w, librsvg; - `happy-dom` 20.0.11: high, test-only; - `vitest` 4.1.10: moderate, test-only. The sharp fix (0.35.5) needs `@img/[email protected]`, but `[email protected]` only carries the reviewed license supplement for libvips **1.3.3**. Native packaging with the fixed sharp will therefore likely need a new reviewed supplement in an Ekklesia release, which PR 3 should plan for. ## Not in this PR - linux-x64-glibc Module Package creation, native sharp packaging, a `license` field and `LICENSE` file (ADR 0051), and re-enabling the integration job: PR 3. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

ekklesia-bot added 1 commit 2026-10-09 01:53:32 +00:00

feat: build Signage on its own from the published Ekklesia 0.2.0 packages ... 33bb146349

Signage no longer needs an Ekklesia checkout. A clean clone installs with
`pnpm install --frozen-lockfile` and runs lint, typecheck, test, build, and validate by itself, taking
Ekklesia's module-development packages from Ekklesia's public registry (ADRs 0053 and 0054).

- Dependencies: every `workspace:*` becomes `^0.2.0`. @ekklesia/module-pack is added as a
  devDependency pinned exactly to 0.2.0, as ADR 0053 requires; it is not invoked yet. No
  @ekklesia/contracts dependency. drizzle-orm stays a direct dependency, satisfying the adapter's
  optional peer.
- .npmrc points the @ekklesia scope at
  https://git.riverofglorymn.org/api/packages/River_of_Glory_Church/npm/ with no credential, because
  reading needs none.
- pnpm-workspace.yaml holds this repository's pnpm settings only:
  - `allowBuilds: esbuild: true`, as the platform's standalone fixture does;
  - exact-version minimumReleaseAgeExclude entries for the 0.2.0 train, which pnpm 11 otherwise holds
    back on its release day;
  - the platform's narrowly scoped override for GHSA-67mh-4wv8-2f99 (esbuild via drizzle-kit), which
    Signage inherited while it built inside Ekklesia's workspace.
- engines.node `>=24.11.0 <25` and packageManager `[email protected].0`, both from Ekklesia 0.2.0. Node
  24.18.0 goes in .node-version for CI, as in Ekklesia.
- biome.json carries the platform's Biome configuration, which `biome lint` used to pick up from the
  workspace root, so lint rules are unchanged.
- pnpm-lock.yaml is Signage's own: registry tarballs with integrity hashes, and no workspace or file
  links.
- `prepack` runs this package's own build instead of the workspace root's turbo.
- `pnpm validate` (scripts/validate-module.mjs) checks the built package and its migrations with the
  published SDK parsers only:
  - the manifest, its identity, and its entrypoints;
  - that the built runtime's id, version, and database ABI match the manifest;
  - that the built schema metadata is plain, namespaced, and has module-internal foreign keys;
  - the SDK compatibility range;
  - that the migration journal and policy agree.

  Core's own `modules:validate` and `migrations:validate` are not published. What only an Ekklesia
  installation can check is named in the script.

Removed: ci/assemble.sh, ci/platform.env, ci/pnpm-lock.yaml, ci/update-lock.sh. The lint, typecheck,
test, and build jobs check out only this repository; build also runs `pnpm validate`. The integration
job stays disabled. Its first step is now an explicit placeholder rather than the deleted assembly,
and its explanation says it returns when Signage is a canonical linux-x64-glibc Module Package
installed into Ekklesia's generic image.

No source, behaviour, schema, or version change: Signage stays 0.1.2.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Zayin_Admin approved these changes 2026-10-09 02:18:26 +00:00

Zayin_Admin merged commit e7f7404d35 into main 2026-10-09 02:18:39 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Zayin_Admin

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

Joey Zayin_Admin ekklesia-bot

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Zayin/Signage#11