ある日pnpmのlockファイルが壊れたときの対処

お疲れ様です。テテマーチ株式会社のProductUnitでSINIS for Instagram開発チームに所属しています、tenshin_yです。

TL;DR

当時の状況

現在SINIS for Instagramのフロントエンドは Next.jsを採用していて、パッケージマネージャーにはpnpmを採用しています。

そのフロントエンドのリポジトリを、以前弊テックリードが書いた記事にあるように、毎週パッケージガーデニングをしているのですが、ある日私がガーデニングしにいくとエラーを吐いたdependabot発行のPRの姿が...

ローカルは壊れていなかったよなと思って最新ブランチをpullして見てみるとしっかりWARNが出ていました。それでも動くので、node_modulesに既にインストールされたモジュールで動作していたみたいです。

膨大な行のlockファイルを人力でチェック→手修正するのは、なかなか無理があるのでpnpm公式を見ていると、

--fix-lockfile 破損した lockfile の項目を自動的に修正します。引用：https://pnpm.io/ja/cli/install#--fix-lockfile

こんなオプションがありました。これを叩いてリモートに取り込んだら、dependabotが発行したPRのCIが正常に通り始めました。これでまたライブラリガーデニングできますね。🎉

lockファイルが壊れた時用のセーフティがあるとは思っていなかったが非常に助かる。
普段makeをコマンドランナーにしてコンテナに渡すコマンドを簡略化していると、なかなか元のコマンドのドキュメントを読むことも少なくなるが、なんかどうにかなる情報があるという教訓を得た。
ブランチ運用とルールを見直す必要がありそうだと気がつけた。

特に、mainから切った開発ブランチに何かしら追加でモジュールをインストールして、その開発ブランチが長期にわたってmainに取り込まれない場合、

ガーデニングする
→lockファイルに変更が入る
→lockファイルが開発ブランチと別のコミットログを形成する
→開発完了！しかしコンフリクトして手直しが必要な状況に...。

またgit戦略の話は別の機会にできると良いかなと思います。

テテマーチでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ herp.careers

エンジニアチームガイドはこちら！ tetemarche01.notion.site