chore(deps): weekly dependency update (2026-09-26)

[robertying]

Summary

Weekly automated dependency update. corepack use pnpm@latest + pnpm update --latest -r were run, followed by lint/build verification and a dev smoke test.

Bumped

• packageManager: pnpm 12.4.1 → 12.6.0
• @primer/css: 22.3.1 → 22.3.2 (patch)
• @types/node: 26.4.1 → 26.6.3 (minor)
• eslint-config-next: 16.3.5 → 16.3.6 (patch)
• fs-extra: 11.4.0 → 11.4.1 (patch)
• next: 16.3.5 → 16.3.6 (patch)
• prettier: 3.9.6 → 3.9.9 (patch)

All other deps (react, react-dom, tailwindcss, typescript alias, @typescript/native, sharp, etc.) were already at latest and unchanged.

Major bump capped back down

pnpm update --latest resolved eslint 10.11.0 (major bump from 9.39.5), but this broke pnpm lint:

TypeError: Error while loading rule 'react/display-name': contextOrFilename.getFilename is not a function

pnpm peers check confirms the root cause: eslint-plugin-react@7.37.5, eslint-plugin-jsx-a11y@6.10.2, and eslint-plugin-import@2.32.0 (all pulled in transitively via eslint-config-next) declare peer ranges that top out at eslint 9.x and don't yet support eslint 10. This is exactly the same issue the thursday repo hit this week with the same eslint-config-next lineage.

Fix applied: capped eslint back to 9.39.5, the latest version within the still-supported 9.x major. Not a code bug — purely an unsupported-version gap in the ESLint plugin ecosystem. Re-ran pnpm install + pnpm lint afterward; both are clean with no peer-dependency warnings.

Checks (local)

• pnpm lint: PASS (after capping eslint to 9.39.5)
• pnpm build: PASS (next build --webpack, using next 16.3.6)
• pnpm dev smoke test: PASS — server started clean (no stack traces/warnings besides the expected useTypeScriptCli experimental-flag notice), GET / returned a real 200 with full rendered blog content (port 3000 was occupied by an unrelated process in this sandbox, so the server auto-selected 3001; not a project issue)

useTypeScriptCli: false workaround (next.config.ts) — obsolescence check

This repo lands on next@16.3.6, which is the version confirmed (via a sibling repo's update this week) to add a /^tsc\d+$/ fallback in runTypeScriptCli.js's bin-resolution logic — confirmed present here too:

const tscBin = ... ?? (Object.entries(packageJson.bin ?? {}).find(([name]) => /^tsc\d+$/.test(name))?.[1]);

@typescript/typescript6@6.0.2's package.json still only exposes "bin": { "tsc6": "./bin/tsc6" } (no plain tsc), which is exactly what that regex fallback is designed to catch.

I verified empirically (temporarily flipping the flag, rebuilding, then reverting before committing — the committed code is unchanged): with useTypeScriptCli: true, pnpm build completes successfully and the "Experiments (use with caution): ⨯ useTypeScriptCli" notice disappears from the build/dev output, with type-checking still running correctly.

Conclusion: this workaround now looks safe to remove, since next's own CLI detection can resolve tsc6 via its bin field on next ≥ 16.3.6. I did not remove it myself per instructions — flagging for a maintainer decision, since removing it changes the type-checking code path (TS-CLI vs API-based checker) and deserves an explicit choice.

GitHub Actions pins (CI.yml)

Checked latest tags for all four pinned actions via git ls-remote --tags:

• actions/checkout@v7 → latest is v7.0.1, already tracking latest major (no v8 exists)
• actions/setup-node@v7 → latest is v7.0.0, already tracking latest major (no v8 exists)
• pnpm/action-setup@v6 → latest is v6.1.0, already tracking latest major (no v7 exists)
• actions/cache@v6 → latest is v6.1.0, already tracking latest major (no v7 exists)

No changes needed — this repo already pins Actions by floating major-version tags (@v7, @v6), which automatically pick up the latest minor/patch. No major bumps are pending for any of these four.

Dockerfile

No changes. FROM node:lts-alpine is an intentional floating tag (per task instructions, left as-is). No other hardcoded/pinned versions found in the Dockerfile — corepack enable && corepack install picks up the packageManager field from package.json automatically, so the pnpm bump above flows through without any Dockerfile edit.

Needs review

• useTypeScriptCli: false in next.config.ts — per the analysis above, this looks safe to remove now that next@16.3.6 has a tsc6-aware fallback, but I left the code untouched since flipping it changes the type-checking code path and deserves an explicit maintainer decision.
• eslint capped at 9.39.5 — this should be revisited once eslint-plugin-react, eslint-plugin-jsx-a11y, and eslint-plugin-import (via a future eslint-config-next release) declare eslint 10 support.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_018cQGMQEWosyap8seKE16Be

---

Generated by Claude Code