feat(template): a module that builds and loads — Phase 5 slice 1
The kit's `template/`: a complete, minimal Runic Gateway module a reader copies,
renames, and runs before reading a chapter. Slice 0 landed the workflow that runs
it; this is the tree that workflow was written against, so the `template` job
arms itself with no edit to the guard.
Installed into a real core it adds one public page at `/examplegame/status`, a nav
row pointing at it, one API route described in an OpenAPI fragment core merges,
one table created by an idempotent schema fragment and dropped by a purge file,
and both lifecycle hooks. That is deliberately less than a real module does; what
it is complete about is the shape — every seam used once, with the reasoning next
to it.
Four decisions, settled with the org lead:
1. **Public tier only, plus the lifecycle hooks.** §2.11.1 d1's "one public route",
plus enough to show the whole vertical seam once. Admin and player tiers become
worked examples quoted from module-uo in chapter 2 rather than two thirds of a
tree the reader deletes on day one.
2. **The release workflow ships as a file, in BOTH flavours** — `.gitea/` and
`.github/`. Neither runs where it sits (a workflow is only read from a
repository root) and each arms itself when the reader's copy is its own repo.
Packaging is the part of a module that cannot be guessed at, and the kit's
audience is outside this org, so assuming Gitea would have been assuming our
own deployment. Core installs from a URL and does not care where the release
lives — only that the host is on the operator's `MODULE_SOURCE_HOSTS`.
3. **A rename checklist that CI verifies**, not a rename script. `template/README.md`
carries the table; `scripts/checkRenameSites.js` holds it against the tree in
both directions — an unlisted file that still carries the placeholder fails, and
so does a listed file that no longer does. The second half is the one usually
left out and the more valuable: a row that has stopped matching reads as
instructions to edit something that is not there. Same rule core's identifier
check follows about its own exemptions. It has its own ten-test suite, run by
CI as `node --test`, because a check that has never been shown to fail is a
check nobody knows the state of.
4. **A neutral invented game.** One deviation from the literal answer, forced by
decision 3: the id is `examplegame`, not `example`. The checklist check is a
text search, and `example` occurs in ordinary English ("for example") all over
prose that is not a rename site — a placeholder that cannot occur by accident is
what makes the check answerable instead of a source of false alarms someone
learns to ignore.
**The pin moves to the 1.4.0 bump** (website `edge` 1b692bf), which is what
`template/module.json` declares as `coreApi`. Slice 0 pinned its parent, before
1.4.0 existed, so `checkCoreApi.js` arms for the first time here — it asserts
EQUALITY, and its failing on the next contract bump is the system working.
Also in CI: the client tests now run AFTER the build (two of them read the built
chunk and skip without one — run first, the job reports green while asking nothing
about the artifact that ships), and `check:swagger` verifies the committed
fragment is current.
## The finding: an UPDATE that changes nothing does not touch ON UPDATE CURRENT_TIMESTAMP
Every suite passed, both guards passed, the chunk built, the module loaded into a
real core and the page rendered correctly. Two hours later the same page said the
world was offline, and it was wrong.
`updated_at` was declared `ON UPDATE CURRENT_TIMESTAMP`, and MariaDB fires that
only when an UPDATE actually CHANGES a value. The boot refresh writes the same
numbers every thirty seconds — which is exactly what a quiet game looks like — so
the timestamp froze at the first write, the row crossed the freshness window, and
the model correctly reported a stale row as offline. Verified against the live
database: two hours of refreshes, `updated_at` still the boot timestamp.
No test in this repo could see it. The model takes its clock as an argument, and
nothing in a suite runs the same UPDATE twice against a real database. It is only
visible as a page that was right when you looked at it and wrong an hour later.
The writer now sets `updated_at = CURRENT_TIMESTAMP` explicitly and the column
drops the clause that was not doing what it looked like it was doing; both carry
the reasoning. Re-verified end to end: the timestamp advances every interval and
the API reports fresh.
Falling out of the fix, the schema fragment gained the rule the reader hits next:
**changing a table is an ALTER, never an edit to its CREATE** — `CREATE TABLE IF
NOT EXISTS` does nothing when the table exists, so an edited column definition
takes effect on a fresh install and on no existing one, which is the worst
possible split because your development database is usually the fresh one.
## Verified
- 29 server tests, 18 client tests, 10 kit-script tests; `check:imports`,
`check:externals`, `check:swagger` and `checkCoreApi` all green, run in CI's own
order from a clean `npm ci`.
- Browser smoke (MODULE_API.md §7.7) against a real core built from the pinned
ref: module `started`, published on `/api/v1/public/modules`, chunk served
`no-cache` with the right MIME from the entry's directory while `module.json`
and the server source 404, script tag injected after core's bundle, the page
rendering inside core's own chrome, the nav row interleaved into the public
header between Wiki and About, SPA navigation into it from another page, the
module's path and schema and tag merged into `/api/docs.json`, and
`[examplegame] registered against core API 1.4.0` in the console with no CSP
report and no React error.
Refs: MODULE_SYSTEM.md §2.11.1 (slice 1), MODULE_API.md §2.x, §3.x, §5.1, §7.7.
Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
145
template/README.md
Normal file
145
template/README.md
Normal file
@@ -0,0 +1,145 @@
|
||||
# The template module
|
||||
|
||||
A Runic Gateway module that builds, loads, and does almost nothing. Copy it,
|
||||
rename it, and you have a running module before you have read a chapter.
|
||||
|
||||
Installed into a core, it adds:
|
||||
|
||||
- **one public page** at `/examplegame/status`, and a nav row pointing at it;
|
||||
- **one API route**, `GET /api/v1/public/world/status`, described in an OpenAPI
|
||||
fragment core merges into its own `/api/docs`;
|
||||
- **one table**, `examplegame_world_status`, created by an idempotent schema
|
||||
fragment and dropped by a purge file;
|
||||
- **both lifecycle hooks**, so there is something to see at boot and at shutdown.
|
||||
|
||||
That is deliberately less than your module will do. What it is *complete* about is
|
||||
the shape: every seam a real module uses is here once, with the reasoning next to
|
||||
it, and CI proves the whole thing still builds against a pinned core.
|
||||
|
||||
## The tree
|
||||
|
||||
```
|
||||
module.json what core reads first — id, version, coreApi, mounts
|
||||
server/
|
||||
index.js register(ctx, api) — the entire server-side handshake
|
||||
core.js the lazy accessors over ctx; read this second
|
||||
boot.js onBoot / onShutdown
|
||||
db/schema.sql idempotent, replayed every boot
|
||||
db/purge.sql destructive, run only by an explicit admin purge
|
||||
model/worldStatus/ the .db.js / .model.js pair
|
||||
router/public/ one router, one controller, the #swagger annotations
|
||||
swagger/doc.js tags and schemas the annotations refer to
|
||||
scripts/checkImports.js the module boundary, enforced
|
||||
scripts/swaggerFragment.js generates swagger-fragment.json from your own routes
|
||||
test/ the suites — start with entry.test.js
|
||||
client/
|
||||
vite.config.js the library build: anchored aliases, external: []
|
||||
src/entry.jsx registers routes and nav at evaluation time
|
||||
src/core.js what core hands you: the seven-member UI kit
|
||||
src/shim/ the four shared dependencies, re-exported from core
|
||||
src/routes/public/ the page
|
||||
scripts/checkExternals.js asks the BUILT chunk whether a bare import survived
|
||||
test/ build.test.js and registration.test.js
|
||||
.gitea/workflows/release.yml packaging CI — Gitea
|
||||
.github/workflows/release.yml the same, for GitHub. Keep one, delete the other.
|
||||
swagger-fragment.json generated; commit it
|
||||
```
|
||||
|
||||
Neither workflow runs while it sits inside the kit — a workflow is only read from
|
||||
a repository root. They arm themselves when your copy is a repository of its own.
|
||||
|
||||
## Build it
|
||||
|
||||
```bash
|
||||
npm ci --prefix server
|
||||
npm test --prefix server
|
||||
npm run check:imports --prefix server
|
||||
|
||||
npm ci --prefix client
|
||||
npm run build --prefix client # → client/dist/entry.js, the chunk that ships
|
||||
npm run check:externals --prefix client
|
||||
npm test --prefix client # build FIRST: two of these tests read the chunk
|
||||
```
|
||||
|
||||
`npm test` in `client/` passes with no build, by skipping the tests that need one.
|
||||
That is on purpose — the suite has to be runnable before the build — and it means
|
||||
**a CI job that tests without building is a job asking nothing.** Build first.
|
||||
|
||||
Regenerate the OpenAPI fragment whenever a route or an annotation changes:
|
||||
|
||||
```bash
|
||||
npm run swagger --prefix server # writes swagger-fragment.json
|
||||
npm run check:swagger --prefix server # fails if it is stale
|
||||
```
|
||||
|
||||
## Install it
|
||||
|
||||
Three supported ways, and none of them builds anything on the operator's machine:
|
||||
|
||||
1. **Admin → Modules**, pasting the URL of an install manifest — the JSON the
|
||||
release workflow attaches beside the tarball. This is how an operator installs
|
||||
your module.
|
||||
2. **The `MODULES` environment variable**, `<id>@<version>=<manifest URL>`, for a
|
||||
deployment that declares its module set rather than clicking it.
|
||||
3. **A directory on the volume.** Copy this whole tree to `<website>/modules/<id>/`
|
||||
and restart. The fastest loop while you are developing.
|
||||
|
||||
For (3): **copy, do not symlink.** The loader lists directory entries and a
|
||||
symlink is not a directory, so a linked module is skipped in silence.
|
||||
|
||||
## Rename it
|
||||
|
||||
Change `id` in `module.json` first, then work down the list. Nothing here is
|
||||
subtle, and the suites catch most of a half-finished job: `schema.test.js` fails
|
||||
the moment a table name stops matching the id, and `registration.test.js` fails
|
||||
when a nav row stops matching its route.
|
||||
|
||||
Your id must match `^[a-z][a-z0-9-]{1,31}$`, must equal the directory name core
|
||||
loads you from, and becomes your table prefix — so **no hyphen unless you enjoy
|
||||
backticking table names**.
|
||||
|
||||
<!-- rename-sites -->
|
||||
|
||||
| File | What to change |
|
||||
| --- | --- |
|
||||
| `module.json` | `id`, `name`, `version`, the `mounts` prefix, `capabilities` |
|
||||
| `server/package.json` | package `name` and `description` |
|
||||
| `server/core.js` | the message every accessor throws |
|
||||
| `server/boot.js` | the placeholder world name |
|
||||
| `server/db/schema.sql` | every table name — the prefix must be your id |
|
||||
| `server/db/purge.sql` | the same table names |
|
||||
| `server/model/worldStatus/worldStatus.db.js` | the `TABLE` constant |
|
||||
| `server/router/public/world.router.js` | the `#swagger.tags` name |
|
||||
| `server/swagger/doc.js` | the tag, and the `Examplegame…` schema prefix |
|
||||
| `server/scripts/swaggerFragment.js` | the generated fragment's `info.title` |
|
||||
| `server/test/_fakes.js` | `ctx.moduleId` |
|
||||
| `server/test/worldStatus.test.js` | the fixture's world name |
|
||||
| `server/package-lock.json` | **regenerated** — `npm install --prefix server` |
|
||||
| `client/package.json` | package `name` and `description` |
|
||||
| `client/vite.config.js` | the guard plugin's `name` |
|
||||
| `client/src/core.js` | the console tag on the identity check |
|
||||
| `client/src/shim/rg.js` | the console tag on the missing-global error |
|
||||
| `client/src/entry.jsx` | `ID`, and every route path and nav `to` |
|
||||
| `client/test/registration.test.js` | the example path in the comment |
|
||||
| `client/package-lock.json` | **regenerated** — `npm install --prefix client` |
|
||||
| `swagger-fragment.json` | **regenerated** — `npm run swagger --prefix server` |
|
||||
|
||||
<!-- /rename-sites -->
|
||||
|
||||
That table is checked. `scripts/checkRenameSites.js` at the root of this kit
|
||||
compares it against the tree on every pull request: a file that still mentions the
|
||||
placeholder and is not listed fails the build, and so does a listed file with
|
||||
nothing left to rename. A checklist nobody verifies is a checklist that is wrong
|
||||
by the second edit.
|
||||
|
||||
Two things you do **not** rename: the mount prefix `/world` need not be your id
|
||||
(the server's prefix namespace is shared with core's, and `/status`, `/settings`,
|
||||
`/version` and `/contact` are already taken), and the `world` / `worldStatus`
|
||||
naming throughout is ordinary vocabulary you should replace with your own domain's
|
||||
when you replace the feature.
|
||||
|
||||
## Licence
|
||||
|
||||
GPL-3.0-or-later, like everything else in this project — see
|
||||
[LICENSE.md](LICENSE.md). This directory is meant to be copied and made yours; it
|
||||
carries that licence, and so does anything derived from it.
|
||||
Reference in New Issue
Block a user