ci(workflows): trigger monorepo-build on main and dev

[elycruz]

Summary

.github/workflows/monorepo-build.yml still triggered only on the monorepo branch, which #76 renamed to main — so no build has been running for any PR into main or dev. This points the triggers at [ main, dev ] and fixes the other latent breakage that would have surfaced the moment the workflow started running again.

Work unit: 118-ci-branch-hooks

Closes #118

Changes

All changes are confined to .github/workflows/monorepo-build.yml.

1. Triggers — push.branches and pull_request.branches are now [ main, dev ] (both branches exist on the remote).

2. Removed a step that could never have succeeded — the workflow ran pnpm link-and-build:packages, a script that is not defined anywhere: not in root package.json, not in any packages/*/package.json, not in node_scripts/. It was renamed to link-packages in 84c0578 ("renamed 'link-and-build*' script to 'link-packages'") and the workflow was never updated. Even with the triggers fixed, CI would have failed on this step with ERR_PNPM_NO_SCRIPT.

   Fix chosen: call pnpm build directly rather than re-adding the alias. node_scripts/tasks/link-packages.mjs does two things — a series of global pnpm link . / pnpm link <name> calls, and then pnpm run build. The linking half is dead weight under pnpm workspaces: pnpm i already creates the workspace symlinks (verified in this worktree — node_modules/fjl -> ../packages/fjl, plus fjl-validator and fjl-inputfilter), and injecting global links over the workspace links in CI is a source of resolution drift, not a fix for it. So the only part CI actually needed was pnpm run build. link-packages is left in package.json untouched as a local dev convenience.

3. Node matrix: [18.x, 20.x, 22.X] → [20.x, 22.x, 24.x] — see justification below. Also fixes the stray capital X on 22.X.

4. Action version bumps — actions/checkout v2 → v7, actions/setup-node v2 → v7, pnpm/action-setup v2 → v6. The v2 actions run on a runtime GitHub retired long ago. (These landed in two steps: the first pass went to v4, and the resulting green run annotated every job with "Node.js 20 is deprecated … being forced to run on Node.js 24", so a second commit took them to the current majors, which all declare using: node24.) pnpm/action-setup reads the packageManager field (pnpm@8.13.1) from package.json, so the explicit version: 8 input is dropped — passing both is an error. The pnpm setup step now runs before setup-node, which is what makes cache: 'pnpm' work (store caching added while there).

5. Fixed PUPPETEER_EXE_PATH: $(which chrome) — job-level env: in YAML is not shell-interpolated, so this set the literal seven-character string $(which chrome), not a path. It is now sourced from the setup-chrome step's documented chrome-path output (confirmed against the action's action.yml) and scoped to the pnpm test step. The bare chrome --version smoke step now uses the same output instead of relying on PATH.

Testing evidence

The exact command sequence the workflow now runs (pnpm i → pnpm build → pnpm test) was run locally in the worktree with NODE_ENV=CI/CD and HUSKY=0 set, matching the job env:

Test Suites: 133 passed, 133 total
Tests:       1066 passed, 1066 total
Snapshots:   0 total
Time:        3.874 s, estimated 7 s
Ran all test suites in 3 projects.

pnpm build exits 0. (It emits pre-existing rollup .d.ts warnings about packages/fjl/dist/esm/object/setTheory.d.ts; those are present on main and unrelated to this change.)

The workflow was also verified live on this PR — which is itself the proof the trigger fix works, since opening this PR is what caused a build to run at all. All three matrix jobs are green end to end (pnpm i → pnpm build → pnpm test), with zero annotations after the action bump:

build-and-test (20.x)   pass   55s
build-and-test (22.x)   pass   54s
build-and-test (24.x)   pass   44s

The chrome --version step resolves to a real path on CI now
(/opt/hostedtoolcache/setup-chrome/chrome/stable/x64/chrome --version), confirming the chrome-path output wiring.

The workflow YAML was parsed to confirm it is well-formed, and pnpm@8.13.1 (the pinned packageManager) was confirmed to run on Node 24 — the whole install/build/test run above was done under pnpm 8.13.1 on node v24.16.0, so the new top matrix entry is not speculative.

pnpm lint was not run as a gate: it already fails on main (21 errors / 62 warnings, in vendored docs/*.js, packages/fjl-labs/, and some tests). No JS/TS source files are touched by this PR, so no new lint errors are introduced. Note the lint script is deliberately not wired into this workflow — making it a gate is a separate cleanup, not something to smuggle into a trigger fix.

No git hooks were bypassed; commit-msg, pre-commit, and pre-push (pnpm test && pnpm build) all ran and passed.

Node matrix justification

Line	Status as of today	Verdict
18.x	EOL 2025-04-30	Dropped. No security updates for over a year; testing against it gives a false signal of support.
20.x	Maintenance ended 2026-04-30	Kept as the floor. .nvmrc still pins v20 and root engines.node is >=16, so 20 is the lowest version the repo actually claims to support. Keeping it is the honest floor until those declarations are bumped.
22.x	Active LTS	Kept (and the 22.X typo fixed).
24.x	Active LTS	Added. It is what local development runs, and it was previously untested.

This yields a three-entry LTS ladder — floor, current LTS, newest LTS — which is the same shape as before, just shifted forward one release.

Two related inconsistencies were found but deliberately left alone as out of scope for this PR (they are package-metadata changes, not CI changes):

• Root engines.node is >=16, while packages/fjl/package.json declares the nonsensical ">=16 || >=18 || >=20 || >=22 || >= 24 || >=26" (an or-chain of lower bounds is just >=16), and the four other packages declare ">=16 || >=18". These should be normalized and probably raised to >=20.
• .nvmrc pins v20 while local development is on v24.

Once engines is raised, the matrix floor should move with it.

Manual follow-up required

The third acceptance criterion — make the build a required status check on main — is a repo-settings mutation on a public repo and has intentionally not been applied here. A repo admin should run it after this PR merges and the workflow has reported once.

main is already protected (verified: required_pull_request_reviews, block_creations, and required_conversation_resolution are on) but required_status_checks.checks is empty. A targeted PATCH on just that sub-resource avoids disturbing the existing protection settings:

gh api -X PATCH repos/functional-jslib/fjl/branches/main/protection/required_status_checks \
  --input - <<'JSON'
{
  "strict": false,
  "checks": [
    { "context": "build-and-test (20.x)" },
    { "context": "build-and-test (22.x)" },
    { "context": "build-and-test (24.x)" }
  ]
}
JSON

Notes for whoever runs it:

• The contexts are the matrix-expanded job names, one per Node version — build-and-test alone will never match and would silently never block anything.
• Set "strict": true instead if you also want branches required to be up to date with main before merging. Current protection has strict: false; this command preserves that unless you change it.
• If the matrix changes, this list has to change with it.
• dev has no branch protection at all. Worth mirroring the same required checks there if dev is meant to be an integration branch:
  gh api -X PUT repos/functional-jslib/fjl/branches/dev/protection --input …

Verify afterwards with:

gh api repos/functional-jslib/fjl/branches/main/protection/required_status_checks

Note on publish.yml

.github/workflows/publish.yml carries the same broken PUPPETEER_EXE_PATH: $(which chrome) in two places (job-level and step-level). It is outside the scope of this work unit and is left untouched here, but it should get the same treatment.

🤖 Generated with Claude Code