chore(ci): CIとpublishのNode/npmバージョンを固定

[shinagawa-web]

Summary

• CI (all.yaml / doc.yaml) と publish (publish.yaml) で Node/npm のバージョンがバラバラ(指定なし or ハードコード)だったのを、各 workflow の env で明示的に固定
• package.json に engines.node / engines.npm を追加し、リポジトリが前提とする Node/npm バージョンを明記

Changes

• all.yaml / doc.yaml / publish.yaml の先頭に env: node-version: 24.20.0, npm-version: 11.19.0 を追加
• 各 job の actions/setup-node に node-version: ${{ env.node-version }} を指定
• setup-node の直後に npm install -g npm@${{ env.npm-version }} を追加し、npm 本体のバージョンも固定
• package.json に engines: { node: "24.20.0", npm: "11.19.0" } を追加

Test plan

• all.yaml / doc.yaml / publish.yaml の CI が Node/npm のバージョン固定込みで成功する

[shinagawa-web]

@claude
SKILLは以下を参考にしてください。
https://raw.githubusercontent.com/shokai/agent-skills/refs/heads/main/plugins/sanity-review/skills/sanity-review/SKILL.md

PRのレビューをしてください

[claude]

Claude finished @shinagawa-web's task in 1m 58s —— View job

---

PRレビュー

このPRは "CIとpublishのNode/npmバージョンを固定する" という意図がPR説明と実装で一貫しており、変更内容もシンプルで意図通り実装されています。以下、気づいた点をまとめます。

---

✅ 良い点

• 3つのworkflow (all.yaml / doc.yaml / publish.yaml) 全てに同じ env ブロック(node-version / npm-version)が置かれており、バージョンを一箇所で管理できるようになった。
• actions/setup-node を使う全stepで node-version: ${{ env.node-version }} を統一。以前 publish.yaml にだけあった node-version: '24'(メジャーのみ)というfloating指定が排除されている。
• package.json の engines 追加により、ローカル開発時にもnode/npmバージョンの想定が伝わる。
• action の SHA pin (既存)は維持されており、supply-chain 面のポリシーとも整合的。

---

⚠️ 要検討の指摘

1. root package.json の engines と pkgs/docs/package.json が整合しない

• root: "node": "24.20.0" (完全固定)
• pkgs/docs/package.json:engines.node: ">=18.0" (既存)

pkgs/docs 側だけ緩い範囲になっていて、実質 root の 24.20.0 に縛られる形になります。意図的な差分なのか、追随して更新するのか、方針を統一しておくとよさそうです。(docs 側だけ「もっと古い Node も許す」ケースが実際にあるのか?)

pkgs/typed-api-spec/package.json / examples/* にも engines がないので、公開パッケージ側にも同等の engines を書くかどうかは別途検討ポイントです。

2. engines を完全固定 (24.20.0) にしている点

パッチレベルまで固定すると、開発者の手元で 24.20.1 を使っただけで EBADENGINE の警告(engine-strict=true を有効化していれば失敗)になります。CI と publish には env 側で完全固定を効かせられるので、engines 側は ^24.20.0 や >=24.20.0 のような範囲指定にしておく方が実利用しやすい、というのが一般的な選択です。 現在の方針が「絶対にこのバージョン以外NG」なら現状の書き方でOKですが、意図を確認しておきたいところです。

3. env の key 名 (kebab-case) が GitHub Actions の慣例と異なる

env:
  node-version: 24.20.0
  npm-version: 11.19.0

GitHub Actions の env は基本 NODE_VERSION のような SCREAMING_SNAKE_CASE で書くのが慣例です(shell の環境変数として $NODE_VERSION で参照するケースを想定した命名)。今回は ${{ env.node-version }} の式構文でしか使っていないので動作は問題ないですが、他リポジトリと揃えるなら NODE_VERSION / NPM_VERSION の方が読み手にはわかりやすいです。

4. npm install -g npm@… を全 setup-node 後に走らせているコスト

現状、job ごとに npm install -g npm@11.19.0 が走ります(全 5 か所)。バージョンを固定したい意図は理解できるものの、

• Node 24.20.0 に同梱される npm がすでに 11.x 台なら差し替えの意味は薄い
• 検討候補: package.json に "packageManager": "npm@11.19.0" を追加して corepack で自動選択(Node 24 系ならデフォルトで corepack が利用可能)。この場合 workflow の npm install -g npm@… step は不要にできる可能性があります。

差し替えを行う場合は別PRで良さそうです。

5. actions/setup-node の cache オプション未使用 (今回のスコープ外)

今回のPRのスコープ外ですが、node-version を固定するタイミングで cache: 'npm' (+ cache-dependency-path) を検討するとCIが速くなります。今回は「バージョン固定に集中」でも問題ありませんが、TODO として認識しておくと良いです。

6. ローカル開発向けの .node-version / .nvmrc は追加しない?

engines は「合わないと警告する」だけで nvm/fnm/volta による自動切替は行いません。ローカルでの体験を揃えるなら .node-version (fnm / Volta / asdf 互換)を置いておくと開発者側の nvm 系ツールで自動的にバージョンが揃います。こちらも今回のスコープ外ですが、方針として。

---

🐛 バグ・破壊的変更に関する所感

• 直接的なバグや破壊的変更は見つかりませんでした。
• publish.yaml の release job は Node/npm を使っていない(ncipollo/release-action のみ)ため、env の追加による影響はありません。
• env を workflow 全体に置くと、GITHUB_TOKEN などの secret 経由ではない env として全 step から見えるだけなので、セキュリティ上の懸念もなしです。

---

🧾 チェックリスト整理

• SKILLガイドラインの取得(sanity-review) — 「PR説明と実装の整合」中心にレビュー
• リポジトリのCLAUDE.md確認(存在せず)
• PR差分の確認(4ファイル / +29-1)
• 変更ファイルの詳細レビュー
• レビュー結果の投稿

---

総評

PRの目的(Node/npmバージョンの明示的固定)は正しく達成されており、そのまま merge しても壊れるリスクは低いと感じます。ただし

• engines を完全固定にする意図の再確認(範囲指定にする案)
• pkgs/docs/package.json の engines と揃える方針の明文化

の 2 点は、この PR 内または follow-up で対応するかを判断してから merge するとより安全です。それ以外(packageManager / .node-version / cache オプション)は別PRでもOKなカイゼン提案です。
| Branch: ci/pin-node-npm-version