[claude] Bump the frontend to Node 26 and drop corepack - #15
Conversation
Bumps the docker group with 1 update in the /frontend directory: node. Updates `node` from 20 to 26 --- updated-dependencies: - dependency-name: node dependency-version: '26' dependency-type: direct:production update-type: version-update:semver-major dependency-group: docker ... Signed-off-by: dependabot[bot] <support@github.com>
Node stopped shipping corepack in 25, so on the new base image the `npm install -g corepack@latest` line went from working around an old corepack bug to being required just to get corepack at all. pnpm reads the `packageManager` field itself and switches to the pinned version, so corepack was buying us nothing here: install pnpm and drop the extra tool. This also drops the unpinned `corepack@latest`, which made the image non-reproducible. `corepack enable || true` in the Taskfiles silently did nothing on node 25+, and the README told new devs to run `corepack enable`, which no longer exists. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CI resolved its Node from engines.node (">=20"), which setup-node satisfies
with whatever the runner has cached: 24.19.0 at the time of writing. So tests
ran on 24 while the container shipped 20, and the two drifted silently.
Pin CI with frontend/.node-version instead, which is also what nvm/fnm/mise
read, and leave engines.node as a permissive floor. Raising the floor is a
hard gate because frontend/.npmrc sets engine-strict=true, so it moves to the
oldest Node still supported upstream (22) rather than to the pinned version.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (14)
💤 Files with no reviewable changes (2)
Included review availability: 4 reviews are currently available. Based on recent review activity, included reviews refill at 5 per hour. 📝 WalkthroughWalkthroughThe PR centralizes the frontend Node.js version in ChangesFrontend runtime and tooling
Suggested reviewers: Comment |
 |
|
Overall Grade |
Security Reliability Complexity Hygiene |
Code Review Summary
| Analyzer | Status | Updated (UTC) | Details |
|---|---|---|---|
| C# |  |
Aug 17, 2026 1:06p.m. | Review ↗ |
| Docker | |
Aug 17, 2026 1:06p.m. | Review ↗ |
| JavaScript | |
Aug 17, 2026 1:06p.m. | Review ↗ |
| Shell | |
Aug 17, 2026 1:06p.m. | Review ↗ |
| SQL | |
Aug 17, 2026 1:06p.m. | Review ↗ |
| Secrets | |
Aug 17, 2026 1:06p.m. | Review ↗ |
| PowerShell |  |
Aug 17, 2026 1:06p.m. | Review ↗ |
| CSS | |
Aug 17, 2026 1:06p.m. | Review ↗ |
Important
AI Review is run only on demand for your team. We're only showing results of static analysis review right now. To trigger AI Review, comment @deepsourcebot review on this thread.
The root README still advertised node v20 (EOL, and below the new engines floor, which engine-strict turns into a hard pnpm install failure) and never mentioned pnpm at all. That was survivable while the Taskfiles ran `corepack enable`; now that they don't, a fresh machine needs the pnpm step written down. The playwright composite action was the only place left on setup-node v4 and pnpm/action-setup v3.0.0. It now runs node 26 via .node-version, so move it to the pins the rest of the repo already uses. Also reword the pnpm comment in the Dockerfiles: pnpm switches itself to the packageManager version, so the pinned version is just a bootstrap and doesn't have to be kept in lockstep by hand. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
@coderabbitai review |
✅ Action performedReview finished.
|
The previous wording explained that pnpm overrides this version without saying why it's still pinned, which reads as an invitation to float it to `pnpm@latest` and lose the reproducibility the corepack removal bought. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1 participant
[Claude, autonomous]
Staging PR — never merge; promoted to sillsdev when polished (see FORK.md).
Node 20 is EOL (2026-04-30). This takes the frontend to 26 and cleans up what the bump exposed. Supersedes sillsdev#2522.
node:26(dependabot's commit, unchanged). 26 goes LTS 2026-10-28, EOL 2029-04-30.packageManageritself and switches to the pinned version. Also removes the unpinnedcorepack@latest.frontend/.node-version. It was resolvingengines.node(>=20) to whatever the runner had cached (24.19.0), so tests ran on a different major than the container shipped.engines.node>=20→>=22in all three package.json. Floor only, andfrontend/.npmrcsetsengine-strict=trueso it's a hard gate: it tracks the oldest Node still supported upstream rather than the pinned version.frontend/README.mdtold devs to runcorepack enable. Both fixed, andcorepack enable || true(a silent no-op on node 25+) is gone from the Taskfiles..github/actions/playwright-testswas the last place onsetup-node@v4andpnpm/action-setup@v3.0.0. It now runs node 26 via.node-version, so it moves to the same SHAs (v7.0.0/v6.0.10) and identical inputs as the other five call sites, rather than meeting a new major on two-year-old actions.Not verified here: the docker build, and node 26 itself. The fork runs no docker/deploy workflows, and
fork-ui.yaml/fork-fwlite.yamlkeep their ownnode-version-file: './frontend/package.json', so fork CI tests on 24. Upstream covers both.