Update @bazel/bazelisk and @types/node

[kogai]

npm の devDependencies を更新します。ライブラリ更新の一連の作業のうち、npm 側の安全に上げられる分です。

この PR は #56 の上に積んでいます (base = claude/bump-deprecated-github-actions)。#56 の CI 修正が入っていないと、そもそも CI がテストを実行できないためです。#56 がマージされたら base は自動的に main になります。

変更内容

パッケージ	変更
@bazel/bazelisk	1.7.3 → 1.28.1
@types/node	14.14.25 → 22.20.2

あわせて .npmrc (lockfile-version=1) と .gitignore への node_modules/ 追加。

fast-xml-parser を含めていない理由

3.17.6 には未修正の脆弱性が 2 件あります (GHSA-x3cc-x39p-42qx prototype pollution、GHSA-gh4j-gqv2-49f6 comment/CDATA injection)。影響範囲は <=5.6.0 で、最初の修正版は 5.7.0 です。メジャーをまたぐと xml.parse() から new XMLParser().parse() へ API が変わり、template/typescript/v2/reader.mustache の書き換えを伴うため、テンプレート移行とセットで別 PR にします。

lockfile を v1 のまま維持している理由

(レビューを受けて理由を訂正しました。当初「npm がロックを無視して再解決する」と書いていましたが、実際にはより厳しい失敗です。)

• rules_nodejs 3.1.0 の npm_install は npm_command の既定が "ci" (internal/npm_install/npm_install.bzl) で、WORKSPACE はこれを上書きしていません。npm 6 の npm ci を v3 lockfile に対して実行すると exit 1 で落ちます (Cannot read properties of undefined)。静かな再解決ではなくハード失敗です。
• CI の e2e ジョブは Node 12.x (npm 6) で npm install を実行しており、こちらは exit 0 ですがロックを無視して v1 に書き戻します。

なお現状 @npm を参照している BUILD ターゲットが無いため、Bazel 側の失敗は今のところ顕在化しません。それでも v1 に据え置くのは、npm_install を使い始めた瞬間に壊れる地雷を埋めないためです。lockfile のバージョンは、Node ツールチェーンと rules_nodejs を更新する PR で一緒に上げます。

--lockfile-version 1 を手で渡すだけでは、次に素の npm install を実行した人が v3 に書き換えてしまうので、.npmrc で固定しました。

確認

• .npmrc あり + 素の npm install (npm 10.9.7) → lockfileVersion 1 のまま、package-lock.json に差分なし。.npmrc なし → v3 に書き換わる
• インストール後の実バージョン: bazelisk v1.28.1、@types/node 22.20.2
• bazelisk 1.28.1 が Bazel 3.7.0 を取得して e2e が通ることは、この PR の CI ログで確認済み (Downloading .../bazel-3.7.0-linux-x86_64 → //e2e/go:snapshot_test PASSED)
• Bazel 実行のローカル検証は不可 (releases.bazel.build が egress ポリシーでブロック)

🤖 Generated with Claude Code

https://claude.ai/code/session_01P8rZakwAiz1jpViUX34x1Z

[kogai]

レビュー結果: Approve (軽微な指摘あり)

差分そのもの (package.json / package-lock.json の 2 ファイル、+18/-9) は正しく、手元で検証した範囲では問題ありません。lockfile は v1 のままで、記載バージョンは package.json と完全一致、integrity も 4 パッケージすべて registry と一致、npm install --package-lock-only --lockfile-version 1 でバイト単位に再現できました。bazelisk 1.28.1 が Bazel 3.7.0 を取得して e2e が通ることも、この PR 自身の CI ログで確認できています。ブロッカーとなる指摘 (必須) はありません。ただし lockfile v1 に据え置く理由の説明が、Bazel 側について事実と異なっています。結論 (v1 に据え置く) は正しいのですが、根拠が誤ったままコミットメッセージに残るのは後で判断を誤らせるので、文言だけ直してからマージするのを勧めます。

---

指摘一覧

1. 【推奨】commit message / PR 本文の「Bazel 側も silently re-resolve する」は誤り。実際は hard fail する

• 該当: コミット 570d1bd のメッセージ、および PR 本文「lockfile を v1 のまま維持している理由」節
• 内容: 「rules_nodejs 3.1.0 も CI も v3 lockfile の packages を読めず、dependencies が無いのでロックを無視して再解決する」と書かれていますが、Bazel 側には当てはまりません。rules_nodejs 3.1.0 の npm_install は npm_command の default が "install" ではなく "ci" です (internal/npm_install/npm_install.bzl#L349-L357)。WORKSPACE の npm_install は npm_command を指定していないので default の ci が使われます。
  実際に npm 6.14.18 で v3 lockfile に対して npm ci を実行すると、無視して再解決するのではなく exit 1 で落ちます:

  $ npm6 ci   # package.json は本 PR のもの、lockfile は v3
  npm ERR! Cannot read properties of undefined (reading '@bazel/bazelisk')
  exit=1
  

  一方 CI 側 (.github/workflows/test.yml:45 の npm install) は本文どおりで、v3 lockfile を無視して再解決し、lockfile を v1 に書き戻します (exit 0 を確認)。
• なぜ問題か: 「静かに再解決される」と「ビルドが落ちる」では、あとで lockfile を上げるときの影響評価が変わります。しかも v1 据え置きの根拠としては、実際には より強い 理由 (ビルドが壊れる) なので、正しく書いたほうが説得力があります。
• 補足: 現状 @npm//... を参照している BUILD ターゲットが 1 つも無いため (grep -rn "@npm" --include="BUILD*" --include="*.bzl" --include="WORKSPACE" . が 0 件)、Bazel の外部リポジトリは遅延取得なので bazel test //e2e/go:snapshot_test では npm_install はそもそも走りません。CI ログにも npm_install の痕跡はありません。つまり Bazel 側の理由は「今は理論上の話」でもあります。
• 修正案: 該当箇所を次のような趣旨に書き換える。

  rules_nodejs 3.1.0 の npm_install は npm_command の default が ci で、node_repositories が入れる Node 12.13.0 同梱の npm 6 を使う。npm 6 の npm ci は v3 lockfile を読めずエラー終了するため、@npm を参照するターゲットを追加した時点でビルドが壊れる。CI の npm install (Node 12.x / npm 6.14.16) のほうはロックを無視して再解決し、lockfile を v1 に書き戻す。

2. 【推奨】--lockfile-version 1 を強制する仕組みが無く、次の npm install で v3 に戻る

• 該当: リポジトリルート (.npmrc が存在しない)
• 内容: 今回は手で --lockfile-version 1 を付けていますが、これを保証するものが何もありません。modern npm (手元は 10.9.7) で素の npm install を叩くと lockfile は v3 に上がります。せっかく意図的に据え置いた設定が、次のコントリビューターの 1 コマンドで失われます。
• 修正案: ルートに .npmrc を追加する。動作確認済みです。

  # rules_nodejs 3.1.0 の npm_install (npm_command=ci, 同梱 npm 6) と
  # CI の Node 12.x が lockfileVersion 3 を読めないため v1 に固定する。
  # Node ツールチェーンと rules_nodejs を更新したら削除してよい。
  lockfile-version=1
  

  検証: .npmrc あり → lockfileVersion=1 / なし → lockfileVersion=3。

3. 【任意】CI が npm ci ではなく npm install なので、lockfile が CI で強制されていない

• 該当: .github/workflows/test.yml:45
• 内容: npm install は lockfile と package.json がずれていても通してしまうので、lockfile を維持する意義が CI 上では効いていません。この PR の主張 (「ロックの意味が失われる」) を守るなら npm ci にすべきです。
• 検証: 本 PR の v1 lockfile に対して npm 6.14.18 で npm ci を実行 → exit 0、4 パッケージが正しく入ることを確認済みなので、Node 12.x のままでも切り替え可能です。
• 修正案: - run: npm install → - run: npm ci。ただし本 PR の主題ではないので、別 PR でも構いません。

4. 【任意】PR 本文の「修正は 5.6.1 以降にしかなく」は不正確

• 該当: PR 本文「fast-xml-parser を含めていない理由」節
• 内容: 5.6.1 は npm に公開されていません。advisory の脆弱範囲は <=5.6.0 で、公開されている最初の修正版は 5.7.0 です (5.6.0 の次は 5.7.0、latest は 5.11.1)。npm audit の fixAvailable も 5.11.1 (isSemVerMajor) を返します。
• 修正案: 「5.6.1 以降」→「5.7.0 以降 (現行 latest は 5.11.1)」。なお xml.parse() → new XMLParser().parse() の API 変更が必要という判断自体は正しく、generated/typescript/v2/reader.ts:8 が xml.parse(...) を使っていることを確認しました。この PR で混ぜないという分割方針に異論はありません。

5. 【任意】@types/node は現状どのツールからも使われていない (この PR の問題ではないが、フォローアップ候補)

• 該当: package.json:12
• 内容: typescript が dependencies にも devDependencies にも無く、CI が実行するのは make test (.github/workflows/test.yml:26) と npx bazelisk test //e2e/go:snapshot_test (同 46) だけで、tsc を走らせる箇所はどこにもありません (grep -rn "tsc" で Makefile の --language typescript しかヒットしません)。したがって @types/node の bump は現時点では何も検証されません。
• 検証: 念のため手元で型チェックを回しました。npx -p typescript@5.9 tsc -p tsconfig.json --noEmit → エラー 0 件。--listFiles で generated/typescript/v2/{code,mixed,model,reader}.ts の 4 ファイルすべてが対象に入っていること、@types/node 22.20.2 と undici-types が読み込まれていることを確認済みです。tsconfig.json は target: es5 かつ skipLibCheck: true なので、@types/node 22 の modern な .d.ts でも問題になりません。したがって bump 自体は安全です。
• 補足 / フォローアップ: @types/node 22.20.2 は typesVersions に <=5.6 の互換 shim を持つ程度に新しく、実質 TS 5.x 前提です。将来 typecheck ジョブを足すなら TS 5.x が必要で、CI の Node 12.x とは世代が噛み合いません。tsc --noEmit を CI に足す PR を別途立てると、@types/node が飾りでなくなります。

6. 【任意】Makefile:4 の BZL_BIN は壊れやすい (既存の問題、この PR で持ち込まれたものではない)

• 該当: Makefile:4 — BZL_BIN := $(shell npx bazel info bazel-bin)
• 内容: 2 点。
  1. := の即時評価なので、make test を含む すべての make 実行時に npx bazel info bazel-bin が走ります (schema ターゲット以外では不要)。
  2. npx bazel は node_modules があるときだけ解決します。@bazel/bazelisk は 1.7.3 / 1.28.1 のどちらも bin: {bazelisk, bazel} を持つので (registry で両バージョン確認済み、node_modules/.bin/bazel の存在も確認)、この PR で解決性が壊れることはありません。ただし haskell ジョブには setup-node も npm install も無いため node_modules が存在せず、npx は registry へフォールバックします。npm に bazel という名前のパッケージは存在しない (registry.npmjs.org/bazel → 404) ので毎回失敗し、$(shell) がそれを握り潰して BZL_BIN が空文字になります。結果として make schema は cp -r /v2/ schema/v2/ を実行することになります。
• 修正案: 遅延評価にし、BZL を再利用する。

  BZL := npx bazelisk
  BZL_BIN = $(shell $(BZL) info bazel-bin)

• 本 PR の範囲外なので、別 issue / 別 PR で。

7. 【任意】package.json のメタデータが軒並み古い (既存、フォローアップ候補)

いずれもこの PR で持ち込まれたものではなく、マージをブロックする理由にはなりませんが、まとめて掃除する PR の価値はあります。

• package.json:4 — "description": "## Prior Art"。README からの貼り付け残り。
• package.json:5 — "main": "sandbox.js"。sandbox.js はリポジトリに存在しません (確認済み)。
• package.json:19 — "test": "echo \"Error: no test specified\" && exit 1"。実際のテストは make test と bazelisk test なので、npm test を叩いた人を誤解させます。
• package.json:23,29,31 — repository / bugs / homepage が kogai/onix を指しています。正しくは kogai/onix-codegen。
• package.json:15-17 — 公開する予定が無いパッケージに peerDependencies があります。公開しないなら "private": true を足したほうが意図が明確です (peerDependencies は publish しない限り誰にも効きません)。

---

検証したこと / できなかったこと

検証済み (実行したコマンド・参照した情報源)

主張	結果	方法
lockfileVersion が 1 のまま	✅ 正しい	package-lock.json を直読み → "lockfileVersion": 1
lockfile のバージョンが package.json と一致	✅ 一致	bazelisk 1.28.1 / @types/node 22.20.2 / fast-xml-parser 3.17.6、undici-types 6.21.0 は @types/node 22 の唯一の推移依存 (registry で確認)
integrity が正しい	✅ 4/4 一致	各パッケージの registry.npmjs.org/<name>/<version> の dist.integrity と突合
lockfile が再現可能	✅ バイト一致	npm install --package-lock-only --lockfile-version 1 → diff -u で差分 0
rules_nodejs 3.1.0 が自前の npm を使う	✅ 正しい	npm_install.bzl の get_npm_label() → @nodejs_<platform>//:bin/npm。node_repositories.bzl:171-174 の node_version default は 12.13.0 (= npm 6 系)
npm 6 が v3 lockfile を尊重しない	⚠️ 半分正しい	npm@6.14.18 を実際に入れて実験。npm ci → exit 1 で失敗、npm install → exit 0 でロックを無視し v1 に書き戻し。v3 lockfile に dependencies キーが無いことも確認 (キーは name/version/lockfileVersion/requires/packages)
bazelisk 1.28.1 が Bazel 3.7.0 を扱える	✅ 正しい	bazelisk v1.28.1 の repositories/gcs.go:198 が https://releases.bazel.build/{version}/release/{file} を組み立てる。最低バージョンのゲートは core/core.go に無し。決定的な証拠として、この PR の e2e ジョブのログに Downloading https://releases.bazel.build/3.7.0/release/bazel-3.7.0-linux-x86_64... → //e2e/go:snapshot_test PASSED が出ています
npx bazel が解決するか	✅ する (node_modules がある場合)	registry の 1.7.3 / 1.28.1 双方で bin: {"bazel": "bazelisk.js", "bazelisk": "bazelisk.js"}、node_modules/.bin/bazel の存在も確認
CI で tsc が走らないこと	✅ 走らない	.github/workflows/test.yml は make test と npx bazelisk test のみ。typescript は依存に無し
@types/node 22 が型チェックを壊さないか	✅ 壊さない	npx -p typescript@5.9 tsc -p tsconfig.json --noEmit → エラー 0。--listFiles で対象 4 ファイルを確認
fast-xml-parser の advisory	✅ 2 件 moderate	npm audit --json で GHSA-x3cc-x39p-42qx / GHSA-gh4j-gqv2-49f6、range <=5.6.0、fixAvailable: 5.11.1 (major)。CI ログの「found 2 moderate severity vulnerabilities」とも一致

なお bazelisk 1.28.1 は platforms/platforms.go:131-152 に「Bazel 4.1.0 未満では darwin/arm64 → x86_64 にフォールバックする」処理を持っています。1.7.3 にはこれが無いので、Apple Silicon で Bazel 3.7.0 を使う開発者にとってはむしろ改善です。

検証できなかったこと

• releases.bazel.build が egress ポリシーでブロックされているため、この環境で bazelisk を実行して Bazel 3.7.0 を取得することはできませんでした。→ 代わりに bazelisk のソース (URL 組み立てとバージョンゲートの有無) を読み、この PR の CI ログで実際のダウンロードと成功を確認しています。
• 同じ理由で rules_nodejs の npm_install を Bazel 経由で実際に走らせることはできていません。→ 代わりに npm@6.14.18 を直接入れて npm ci / npm install の挙動を再現しました。
• editeur.org がブロックされているため make schema は未検証です (指摘 6 の BZL_BIN 空文字の実害も、コード読解による推論です)。
• haskell.org がブロックされているため make test (stack) はローカル実行できていません。
• レビュー時点で Test haskell codes ジョブは in_progress (ログ取得は 404) でした。Test e2e は success です。この PR は Haskell コードに触れていないので影響は無いはずですが、マージ前に緑を確認してください。

---

Generated by Claude Code

[kogai]

レビューありがとうございます。推奨 2 件を反映しました (d3394d7)。

推奨 1: npm_install の既定は ci であり、v3 lockfile ではハード失敗する

こちらの記述が誤りでした。「npm がロックを無視して再解決する」と書きましたが、実際には npm ci が exit 1 で落ちる、という別の（そしてより厳しい）失敗です。「BUILD から @npm を参照しているターゲットが無いので、現状 Bazel 側の議論は机上のものである」という点も、書かなかったのは不正確でした。

結論（v1 に据え置く）は変わらないので、PR 本文の理由を書き直しました。コミットメッセージは push 済みで書き換えられないため、この PR 本文と、後続コミットの記述を正とします。

推奨 2: v1 を強制する仕組みが無い

そのとおりでした。--lockfile-version 1 を手で渡して作っただけなので、次に誰かが素の npm install を実行した時点で v3 に書き換わります。「その時コマンドを打った人の性質」ではなく「リポジトリの性質」にすべきという指摘に同意します。.npmrc を追加しました。

$ printf 'lockfile-version=1\n' > .npmrc
$ npm install   # npm 10.9.7
$ node -e "console.log(require('./package-lock.json').lockfileVersion)"
1
$ git status --short   # package-lock.json に差分なし

あわせて node_modules/ を .gitignore に追加しました。元々入っておらず、checkout 内で npm install した時点で誤コミットの余地がありました。

任意

• CI が npm ci ではなく npm install: ご指摘のとおりロックが強制されていません。ただし CI の変更は今 Make CI runnable again: bump deprecated actions and decouple make test from the schema download #56 側で検証中なので、そちらが緑になってから別途対応します。
• 「5.6.1 以降」は誤り (5.6.1 は未公開、最初の修正版は 5.7.0): 確認しました。fast-xml-parser の移行 PR 側の記述を修正します。ご指摘に感謝します。
• @types/node は現状 dead weight だが安全: tsc@5.9 -p tsconfig.json --noEmit で generated/typescript/v2/*.ts 4 ファイルすべてがエラー 0、という検証まで含めていただけたのは助かりました。
• Makefile:4 の BZL_BIN :=: これは Make CI runnable again: bump deprecated actions and decouple make test from the schema download #56 側で修正しました。実測で make -n test が 18.1 秒 → 0.011 秒になります（この環境では releases.bazel.build が塞がれているため毎回ダウンロードを試みて失敗していました）。ご指摘のとおり BZL_BIN = $(shell $(BZL) info bazel-bin) としています。
• package.json の陳腐化 (description: "## Prior Art"、存在しない main: sandbox.js、exit 1 する test script、kogai/onix を指す URL 群、private 無しの peerDependencies): いずれも実在の問題ですが、依存バージョンの更新とは別の関心事なので、この PR には含めません。別 PR で片付けます。

---

Generated by Claude Code