外部のコーダーさんと一緒に仕事をしていると、上がってくるコードのパッケージマネージャーがバラバラなことがあります。
自分は pnpm で統一したい派なので、一応「pnpm のほうが早いしディスク容量的にもおすすめですよ」とは伝えるんですが、まあ手癖ってあるよなあ、と思いながら毎回 lock ファイルを確認して npm か pnpm かを判断してました。
確認を怠ると lock ファイルが複数作られるし、毎回確認するのが地味に面倒。
package-lock.json ← npm がつくったやつ
pnpm-lock.yaml ← pnpm がつくったやつ
どちらが正とも言えない状態になって、結局どっちかを消して再インストールするはめになります。エラーが起きるわけじゃないけど、じわじわ気持ち悪い。
今回前から気になっていた ni（@antfu/ni）を入れたら快適になったので共有です。niはlock ファイルを自動で検出して、適切なパッケージマネージャーのコマンドを実行してくれるツールです。
ni # → npm install / yarn install / pnpm install を自動判別
ni vite # → npm i vite / yarn add vite / pnpm add vite を自動判別
nr dev # → npm run dev / yarn dev / pnpm dev を自動判別
nun vite # → アンインストールも同様
インストールはこれだけです。
npm i -g @antfu/ni
対応するパッケージマネージャーが入っていなければ、ni が自動でインストールしてくれます。
実は最近、デザイナーなどコーディングがメイン業務じゃない人が、AI を使って細かい修正や開発をするケースが増えてきています。自分としては、最初に「このコマンドを叩けば動きます」と伝えて、あとは各自のペースで作業してもらうスタイルが合っていると思っていて。でもプロジェクトごとに PM がバラバラだと、毎回自力もしくは誰かに確認しないといけなくなります。それは非エンジニアにとって無駄な手間だし、エンジニア側も PM の確認に付き合うのは本来おかしな話です。
本当は統一できていればいちばんいいんですが、外部コーダーの手癖まで揃えるのは現実的じゃないし、bun を使いたいという人に pnpm を強制するのも気が引けます。自分自身も次のプロジェクトからは bun を使いたいと思っていて、でもそのコストを周りに負担させるのは違うよなとも思っていて。
ni がすごいのは「PM をこれに統一しよう」とはせずに、PM のブレをこっち側で吸収するという設計思想です。各自が使い慣れたもので開発してもらいつつ、自分が触るときは ni が勝手に合わせてくれる。
Windows の場合だけ注意
PowerShell に ni という組み込みエイリアス（New-Item）があるので、セッションごとに解除が必要です。
Remove-Item Alias:ni -Force
永続化したい場合は $profile に追記します。
Add-Content $profile "`nRemove-Item Alias:ni -Force -ErrorAction SilentlyContinue"
次回起動から自動で解除されるようになります。
PM が混在する現場、あるいは今後非エンジニアが開発に入ってくる現場では、こういう小さい統一が地味に効いてくるんじゃないかなと思っています。まあそんな話でした。