【入門編】依存関係の「幽霊」を狩る:depcheckとsyncpackでpackage.jsonをクリーンに保つ自動化パイプライン – ビルド・パッケージ管理ツール生産性向上バイブル

依存関係の「幽霊」を狩る:なぜあなたのプロジェクトは重くなるのか?

こんにちは。開発環境の深淵を覗き込み、日々のデプロイメントを「儀式」から「日常」に変えることをミッションとしているエンジニアです。

フロントエンド開発において、`node_modules` はしばしば「ブラックボックス」と呼ばれます。特に、知らぬ間に増殖する不要なパッケージや、モノレポ環境でパッケージごとにバラバラになったバージョン管理は、「依存関係の幽霊(Ghost Dependencies)」を生み出します。

これらが放置されると、ビルド速度の低下、予期せぬ実行時エラー、そして何より「このパッケージ、結局なんのためにあるの?」という負の遺産が蓄積します。今日は、これをCI/CDパイプラインで自動的に浄化する、最強の防衛線を構築しましょう。

—

1. 幽霊を見つけるための「depcheck」

`depcheck` は、ソースコードを解析し、`package.json` に書かれているのに使われていない(未使用)パッケージや、使っているのに `package.json` に書かれていない(暗黙的な依存)を暴くツールです。

インストールと基本セットアップ

まずは開発環境に導入します。

開発用依存関係として追加
npm install –save-dev depcheck

現場で使うための「HelloWorld」的な確認

プロジェクトルートで以下のコマンドを叩いてみてください。

npx depcheck

もし「Unused dependencies」が表示されたら、それはあなたのプロジェクトに不要な荷物が載っている証拠です。ただし、CIで自動化する際は注意が必要です。`depcheck` はあくまで静的解析なので、動的なインポートや設定ファイルでのみ使われているものを誤検知することがあります。

賢い使い方のコツ: `.depcheckrc` を作成し、誤検知を除外する設定をリポジトリで共有しましょう。

.depcheckrc
ignores:

  • “eslint-plugin-” # ESLint系は自動読み込みされるため除外対象にするのが定石
  • “prettier” # 実行時にCLIで呼ぶため、コード内には出現しない

—

2. バージョンの不一致を許さない「syncpack」

モノレポ環境や、複数のパッケージを持つプロジェクトで最も怖いのは「パッケージAではReact 18を使い、パッケージBではReact 17を使っている」といった状況です。これは、ランタイムで地獄のようなバグを引き起こします。

`syncpack` は、依存関係のバージョンを強制的に統一し、不整合をCIで弾くための強力なツールです。

インストール

npm install –save-dev syncpack

なぜこれが「神ツール」なのか

`syncpack list-mismatches` を実行すると、バージョンが揃っていないパッケージが即座に可視化されます。これを手動で直すのは不可能です。以下のコマンドで一括修正します。

バージョンを最も高いものに統一する
npx syncpack fix-mismatches

—

3. CI/CDパイプラインへの組み込み:自動浄化システム

ツールを入れるだけでは意味がありません。「誰かがルールを破った瞬間にCIを落とす」仕組みこそが、最強の開発環境です。

GitHub Actions(またはお使いのCI環境)の `test` または `lint` ステップに以下を組み込んでください。

.github/workflows/lint.yml の一部
jobs:
dependencies:
runs-on: ubuntu-latest
steps:

  • uses: actions/checkout@v3
  • name: Install dependencies

run: npm ci

# 不要なパッケージが混入していないかチェック

  • name: Check for unused dependencies

run: npx depcheck

# バージョンの不整合がないかチェック

  • name: Syncpack check

run: npx syncpack list-mismatches

アーキテクトからのアドバイス

`depcheck` は警告レベル(exit code 0)で動かし、`syncpack` は `list-mismatches` を通じて異常終了(exit code 1)させるのが現場でのベストプラクティスです。なぜなら、不要なパッケージは即座にデプロイを止める理由にはなりにくいですが、バージョンの不一致は事故の元だからです。

—

まとめ:なぜ、ここまでやるのか?

「動けばいい」という考え方は、数ヶ月後の自分を苦しめます。

  • depcheck で「不要なゴミ」を掃除することで、ビルドキャッシュの効率が上がり、CIの実行時間が短縮されます。
  • syncpack で「バージョンのゆらぎ」を消すことで、エンジニアは「ライブラリのバージョンが原因ではないか?」と疑う無駄なデバッグから解放されます。

これらをCIに組み込むことは、単なる規律ではなく、「健全な開発サイクルを維持するための投資」です。

今日からあなたのリポジトリにこの防衛線を敷いてください。クリーンな環境こそが、最高のコードを生み出す揺りかごになります。もし詰まることがあれば、いつでも相談してください。あなたの開発が、より速く、より安全になることを願っています!

タイトルとURLをコピーしました