wtclaude
b33d21d71b
Phase 2 of docs/modules/rust/PLAN.md. Phase 1 built five guards and ran them by hand; this repo had no workflows at all, so nothing gated the branch that gets released and there was no way to release it. Three pieces: - **release.yml** — the derived-version engine link, installer and Module-uo already run (conventional-commit subjects since the newest tag; module.json's version survives as a floor; workflow_dispatch as the backdoor), assembling the bundle from an include list and publishing the tarball, the install manifest carrying its sha256, and SHA256SUMS. The tag is the number that ships and CI stamps it into the bundle's own module.json. - **pr-checks.yml** — server tests, check:imports, check:bundle, check:swagger, the client build, client tests and check:externals, plus frozen-manifest. - **frozen-manifest** — clones core at the sha pinned in ci/core-ref.json, generates its route table without this module and with it, and takes the difference. It ran locally against that exact ref: six routes, all documented, no core route moved. That is the first proof by a running core that /rust collides with nothing — phase 1 could only check it by reading, because core mounts /status and /version at a tier root where the loader's own collision probe cannot see them. The bundle carries no node_modules, because the shipped half declares no runtime dependencies (org lead, phase 2). checkBundle.js holds both halves of that: the include list still covers everything server/index.js reaches, and no dependency has appeared without the release learning to pack it. Verified by breaking it — dropping "model" from the list names the exact edit and exits 1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
26 lines
1.7 KiB
JSON
26 lines
1.7 KiB
JSON
{
|
|
"name": "rust-module-server",
|
|
"version": "0.1.0",
|
|
"private": true,
|
|
"description": "Server half of the Rust module — routers, models and the schema fragment core loads at boot",
|
|
"license": "GPL-3.0-or-later",
|
|
"main": "index.js",
|
|
"scripts": {
|
|
"test": "node --test",
|
|
"check:imports": "node scripts/checkImports.js",
|
|
"check:bundle": "node scripts/checkBundle.js",
|
|
"swagger": "node scripts/swaggerFragment.js",
|
|
"check:swagger": "node scripts/swaggerFragment.js --check"
|
|
},
|
|
"engines": {
|
|
"node": ">=20"
|
|
},
|
|
"//dependencies": "There are none, and that is the shape to aim for: everything the shipped half needs arrives on ctx (MODULE_API.md 2.3) - express, express-validator, the database, the logger and the middleware are all core-owned and handed over. If you do add one, remember an operator never builds: your release CI runs npm ci --omit=dev and packs server/node_modules into the tarball, so every dependency is weight in the artifact and a package the operator now runs. scripts/checkImports.js reads this file to decide what the shipped half may resolve.",
|
|
"devDependencies": {
|
|
"express": "^4.19.2",
|
|
"express-validator": "^7.1.0",
|
|
"swagger-autogen": "^2.23.7"
|
|
},
|
|
"//devDependencies": "Test-only and build-only, never shipped. test/_fakes.js builds a REAL express Router and a REAL express-validator, because a fake of either would only ever test the fake - the admin router builds its validation chains at file scope, so a stubbed validator is not something it can be required with. swagger-autogen generates the OpenAPI fragment; pin it to the same major core uses, so the fragment and the spec it merges into come out of one tool."
|
|
}
|