wtclaude
e4af7dd9a8
Three things, all about checks that had never met a real chunk.
`checkExternals.js` rejected slice 3's build outright, naming a fragment of
minified JSX as an imported specifier: a button reading "Approve and import"
puts the token immediately before a quote, and no regexp can tell that from a
statement. Same wall the server's `checkImports.js` hit, answered the same way —
a character walk. A mask rather than a rewrite, because a real import has its
keyword outside a string and its specifier inside one.
Writing the test for that false positive found the false NEGATIVE underneath
it: the pattern required whitespace after `import`, so it could not see
`import{useState}from"react"` — the one shape a minified build actually emits,
and the most likely way for a missed alias to reach production. It has never
been able to see it.
`registration.test.js` is new: stand up a fake `window.__rg` with a recording
registry and the real React, import the BUILT chunk, and read back what it
asked for. No DOM, because nothing renders. It holds the agreement that rots
quietly — every nav row points at a route this module actually registered —
rather than restating both lists.
CI now builds before it tests, because both of those read `dist/entry.js` and
skip without it. Run the other way round they are green and asking nothing.
Co-Authored-By: Claude <noreply@anthropic.com>
110 lines
4.5 KiB
YAML
110 lines
4.5 KiB
YAML
# Gate every pull request into `main` on a fast, DB-free check suite, so a broken
|
|
# build or a failing test can't reach the branch that gets released.
|
|
#
|
|
# Mirrors RunicGateway/website's pr-checks.yml — this module is two npm packages
|
|
# shaped like that repo's `server/` and `client/`, and it is loaded into that
|
|
# repo's process, so it is checked the same way with the same Node version.
|
|
#
|
|
# ── What each job is really asking ───────────────────────────────────────────
|
|
#
|
|
# The tests are the ordinary half. The two `check:*` scripts are the interesting
|
|
# one, because they are the acceptance criteria of the module contract itself
|
|
# (docs/website/MODULE_API.md Part 5) rather than of this module's behaviour:
|
|
#
|
|
# • `server: check:imports` — no relative path escapes the module root, and no
|
|
# shipped file resolves a bare specifier. A module that reaches into core's
|
|
# tree works right up until core moves a file, and the whole boundary is
|
|
# worth exactly as much as this check is (§5.1).
|
|
#
|
|
# • `client: check:externals` — the BUILT chunk has no bare imports left. That
|
|
# failure is invisible in source: `import { useState } from 'react'` is
|
|
# correct in every file, and whether it becomes core's React or a bare
|
|
# specifier no browser can resolve is decided by vite.config.js. It has to
|
|
# be asked of the artifact, so it runs after the build. (The other half —
|
|
# a shared dependency being BUNDLED — fails the build itself, from a
|
|
# resolution-time guard inside vite.config.js.)
|
|
#
|
|
# Building the chunk in CI is not only a check: it is how the chunk that ships is
|
|
# produced, since an operator never builds (MODULE_SYSTEM.md §1.14).
|
|
#
|
|
# Not here yet, deliberately, because there is nothing for them to act on until
|
|
# the extraction is further along: the release workflow (the
|
|
# `module-uo-<version>.tar.gz` artifact and its sha256 manifest) and the module's
|
|
# own frozen route manifest, which needs core checked out at a pinned ref
|
|
# (MODULE_API.md §5.3). Each lands with the slice it checks.
|
|
#
|
|
# Enforcement (one-time, in the Gitea UI):
|
|
# Repository Settings → Branches → Branch Protection (rule for `main`)
|
|
# • Enable Status Check
|
|
# • Status check patterns: PR Checks / *
|
|
# Note: Gitea only lists a context in its dropdown after it has reported once,
|
|
# so let this workflow run on one PR first. The `PR Checks / *` glob matches
|
|
# without needing the dropdown, and keeps matching as jobs are added.
|
|
#
|
|
# Runner: the shared self-hosted `ubuntu-latest` runner. These jobs need only
|
|
# Node — no Docker socket, no database.
|
|
|
|
name: PR Checks
|
|
|
|
on:
|
|
pull_request:
|
|
branches: [main]
|
|
|
|
# A newer push to the same PR cancels the in-flight run.
|
|
concurrency:
|
|
group: pr-checks-${{ github.ref }}
|
|
cancel-in-progress: true
|
|
|
|
jobs:
|
|
server-tests:
|
|
runs-on: ubuntu-latest
|
|
timeout-minutes: 20
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
|
|
- uses: actions/setup-node@v4
|
|
with:
|
|
node-version: 20
|
|
cache: npm
|
|
cache-dependency-path: server/package-lock.json
|
|
|
|
# `npm ci` rather than `npm install`: it also proves the lockfile is in
|
|
# sync with package.json instead of silently updating it.
|
|
- name: Install server deps
|
|
run: npm ci --prefix server
|
|
|
|
- name: Run server tests
|
|
run: npm test --prefix server
|
|
|
|
- name: Check the module boundary (MODULE_API.md §5.1)
|
|
run: npm run check:imports --prefix server
|
|
|
|
client-build:
|
|
runs-on: ubuntu-latest
|
|
timeout-minutes: 20
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
|
|
- uses: actions/setup-node@v4
|
|
with:
|
|
node-version: 20
|
|
cache: npm
|
|
cache-dependency-path: client/package-lock.json
|
|
|
|
- name: Install client deps
|
|
run: npm ci --prefix client
|
|
|
|
# The build comes FIRST, and that ordering is load-bearing as of slice 3.
|
|
# Two of the client tests read `dist/entry.js` — the chunk's externals, and
|
|
# what it registers when imported against a fake `window.__rg` — and both
|
|
# skip when there is no build. Run the other way round they skip silently
|
|
# in CI, which is the worst of both: green, and not asking the question.
|
|
- name: Build the client chunk
|
|
run: npm run build --prefix client
|
|
|
|
- name: Run client tests
|
|
run: npm test --prefix client
|
|
|
|
- name: Check the built chunk's externals (MODULE_API.md §3.6)
|
|
run: npm run check:externals --prefix client
|