Dependabotがnpm 12・pnpm 11/12・Bun 1.4に対応：更新前の確認ポイント

パッケージ管理ツールを新しくしたあと、自動更新のPull Requestが止まると困るよね。GitHubは10月20日、Dependabotがnpm 12、pnpm 11・12、Bun 1.4に対応したと発表したよ。今回は、対応したという知らせと、自分のプロジェクトを更新できる状態かを分けて整理しよう。

何が対応したの？

パッケージ管理ツールは、アプリが使うライブラリの取得やバージョンの整理をする道具。Dependabotは、その依存関係を更新する変更案をGitHubへ作る機能だよ。

今回の公式発表の対象は、npm 12、pnpm 11・12、Bun 1.4。github.comの利用者に提供され、GitHub Enterprise Serverでは3.24に含まれる予定とされている。自社サーバーで動くEnterprise Serverを使っている場合、クラウド側の提供開始と同じタイミングだと思わないようにしよう。

対応の意味は、新しいパッケージ管理ツールを使うプロジェクトでもDependabotの更新を受けられること。アプリ本体やCIまで自動で新しい版へ移行してくれる、という発表ではないよ。

ロックファイルとCIも一緒に見る

ロックファイルは、実際に選ばれた依存関係の版を記録するファイル。手元だけ違う管理ツールを使うと、更新案を確認する人の環境とCIの環境がずれてしまうことがある。

ここからは編集部の移行前チェック案だよ。

Bunでは、公式の対応表がテキスト形式のbun.lockを対象とし、古いバイナリ形式のbun.lockbは対象外と説明している。Bunの版だけでなく、保存されているファイルも確認したいね。

なお、確認した対応表にはnpm・pnpmの旧バージョン表記が残っていた。今回追加された版と提供先は10月20日の発表、ファイル形式などの条件は対応表、と出典を分けて読んでいるよ。表記が揃うまでは、対応表だけを見て追加がなかったとも、すべての環境で確認済みとも判断しないでおこう。

まずは更新案を一つ確認する

管理者や担当者と、次の順で小さく試してみよう。本番の管理ツールを、このニュースだけを理由に一斉更新する必要はないよ。

1. 対象リポジトリで、既存のDependabot更新設定と最近の実行状況を確認する。
2. 使用ツール・版・対象フォルダ・ロックファイルの形式をメモする。
3. テスト用ブランチで管理ツールの移行を行い、手元とCIで同じ手順が通るか確かめる。
4. Dependabotの更新案が作られたら、ロックファイルの差分とテスト結果を確認する。
5. 更新案が作られない場合は、対象フォルダ、実行予定、認証や依存解決のエラーを順に切り分ける。

脆弱性一覧のAPI更新とは別の話

同日には、アラートのAPIへ依存バージョンを追加する発表もあった。今回の記事は「更新処理が扱える管理ツールの版」、もう一方は「アラートから取得できるデータ」の変更で、確認する場所が違うよ。

アラートの連携を変更する担当者は、依存バージョンと脆弱性範囲の見分け方へ。更新案の差分を確かめるときは、AIが直したコードをgit diffで確認する手順も参考にしてね。