CI on PR #157 was failing every typecheck with 35 TS2305 errors of the
form 'Module @nitrots/nitro-renderer has no exported member
Housekeeping*' because the workflow's PR fallback mapped to
duckietm/Nitro_Render_V3 @ Dev — and upstream Dev doesn't carry the HK
composers yet. They live on the fork's feat/housekeeping-packets
branch (renderer companion PR #77).
Detect the PR head ref and, when it's feat/housekeeping-panel,
override the default base-ref pairing and point at
simoleo89/Nitro_Render_V3 @ feat/housekeeping-packets so the typecheck
step can resolve the imports. Once the renderer PR lands on
duckietm:Dev this whole special-case block becomes dead code and can
be deleted.
Two follow-ups to the CatalogPurchaseWidgetView fix (6bf3366):
1. CatalogItemGridWidgetView had the same shape — four useCallback
declarations (handleDragStart / handleDragOver / handleDrop /
handleDragEnd) sat below an `if(!currentPage) return null` early
return. When currentPage flipped from null to a real page the hook
count jumped by 4 and React would have thrown "Rendered more hooks
than during the previous render" the moment any consumer rendered
the grid in admin mode. Moved the four useCallback declarations
above the early-return; their bodies are safe pre-load (only
currentPage?.offers is accessed inside handleDrop, optional-chained
already).
2. CI gate — the existing GitHub Actions workflow runs `yarn
typecheck` and `yarn test`, but NOT `yarn eslint`. That's why this
pattern slipped through twice in a row: ESLint flags it locally
but no PR check enforces it. Full `yarn eslint` emits ~900
pre-existing baseline errors (brace-style, indentation,
recommended TS rules — out of scope for this branch), so a blanket
step would always fail. Instead added a focused
`eslint.hooks.config.mjs` + `yarn lint:hooks` script that runs
ESLint with ONLY `react-hooks/rules-of-hooks: error`. Wired into
ci.yml between `typecheck` and `test`. The local repo now has
zero violations of the rule.
3. useSessionSnapshots.test.tsx — added eslint-disable-next-line
comments on the three lines that intentionally violate the rule
(they're the assertions that the broken pattern crashes). Without
the comments the new CI gate would fail on the regression-guard
suite.
Verification: yarn lint:hooks green, yarn typecheck clean, yarn test
209/209.
Node 20 is being removed from GitHub-hosted runners in Sept 2026 and
the actions/checkout@v4 / setup-node@v4 steps were warning on every
run. Set FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true at the workflow
level so they pick up the Node 24 runtime now.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two follow-up fixes after the first CI run failed with TS2307 across
~250 files:
1. The relative symlink target `../../../Nitro_Render_V3` resolves
from inside `Nitro-V3/node_modules/@nitrots/nitro-renderer` to
`Nitro-V3/Nitro_Render_V3` (one too few `..`) — that path
doesn't exist, so tsgo couldn't find the renderer SDK and bailed
on every `@nitrots/nitro-renderer` import. Switch to an absolute
target via ${{ github.workspace }}.
2. The client depends on renderer API additions (`allowUnderpass` on
RoomSettingsData, `sendBackgroundMessage` on IRoomSession, the
NitroConfig Window declaration alignment) that live on
`feat/react19-event-bus` of `simoleo89/Nitro_Render_V3` and not
on `duckietm/Nitro_Render_V3:main`. Point the checkout at the
fork + that branch so tsgo sees what the local working tree sees.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Yarn cleans up anything in node_modules that's not declared in
package.json, so the previous order (symlink → yarn install) wiped
the link and tsgo could not resolve @nitrots/nitro-renderer.
Move the symlink step after both installs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Until now the test suite was authoritative only when run locally;
nothing stopped a commit landing with `yarn test` red. Wire up a
GitHub Actions workflow that gates push + pull_request on both
`yarn typecheck` and `yarn test --run`.
The setup mirrors CLAUDE.md's "Setup walkthrough":
- Check the client into `<workspace>/Nitro-V3`.
- Check `duckietm/Nitro_Render_V3` as a sibling at
`<workspace>/Nitro_Render_V3`, since the build / typecheck wire
the renderer in via filesystem aliases that expect that layout.
- Symlink `Nitro-V3/node_modules/@nitrots/nitro-renderer` →
`../../../Nitro_Render_V3` so `tsconfig.json`'s `include`
entry pointing at `node_modules/@nitrots/nitro-renderer/src/**/*.ts`
actually resolves.
- `yarn install --frozen-lockfile` in both repos, then run
`yarn typecheck` and `yarn test --run` in the client.
Node 22 (matches the local toolchain). Yarn classic, with the
workflow's `setup-node` caching the `yarn.lock` of both repos so
subsequent runs don't reinstall from scratch.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
simoleo89