使用したことのないパッケージマネージャーを比較してみた
以前yarnを使用していた時はイマイチ使いづらかったり、npmが改善を重ねて速度的にも問題ない状況だったため
開発安定性重視のため長い期間npmをメインに使用してきました。開発現場を幾つかみてきた中では
最近では以前よりもbunが早くて安定しているという話を多く聞いたり、GitHub上のReadMeを見てもpnpmを使用する
インストール方法がデフォルトで記載されていることも増えてきたため、現状を検証してみました。
times-検証
せな@sena-v.com今日は比較的余裕あるしbun or pnpmするかスレッドを開くせな@sena-v.combunのメリットとしてpnpm以下パケマネよりもインストールが早いところが上がるけどpnpmの最大メリットであるディスク効率化考えるとどっちがいいかって一概に言えないんだよな、とは言え最近の開発だとnode_modules増えすぎて容量足りないなんてのは見たことないしここだけ考えるとどっちでも感あるせな@sena-v.compnpmはpackage.json内の厳密アクセスが優位っぽいけど割とこれ系で困ることって「共有名メソッドが存在する場合の補完関連で変なの使っちゃってた〜！」くらいでそんなに困ったことないよなせな@sena-v.com強いていうならbunはちょっとOP気味というかできる範囲が多い分install速度早めるためだけに導入して今使ってるライブラリor将来使うライブラリとの相性問題踏まないか？ってところは懸念あるんだよなせな@sena-v.comというかゼロインストールで現状npm install 4.26s user 3.31s こんなもんだし速度優先で考える必要ないなこれせな@sena-v.compnpm install 10.79s user 8.81s vs pnpm install 2.58s user 3.54s仕様上初回はやっぱ時間かかるけど2回目以降は結構良さげだねせな@sena-v.comこれパケマネが厳密になった分直接installしてないものは再度installが必要になってちょっとめんどくさいな、Nextでvanilla-extract使う時"vanilla-extract/css"で使えてたけどpnpm経由だとちゃんと"vanilla-extract/css"をinstallしないといけなくなったせな@sena-v.comまぁでも厳密にやんなさいよ、ってところ以外は悪くないかせな@sena-v.com最終的に初回インストールは遅いってところは結構ネックだからローカル実行ならともかくCIだとコンテナ使い捨てであんまりメリット感じないし、よっぽど似たpackage使い回すプロジェクトが並列で走ってないならまぁええか・・・って感じだなせな@sena-v.comそういえばローカルだとrm -r node_modules && npm installで治るタイプのキャッシュバグ偶に踏むけど、pnpmはリンク貼ってるだけとかいう記事をみるとpnpm i -f必須になるなら余計めんどくさそうな気もするなせな@sena-v.comまぁユースケースに合うか次第なのでねせな@sena-v.comというか最初の目的であるストレージ節約がどうでも良くなった文脈だと自分のプロジェクトでbun vs npmで速度出した方がよくないか？となったのでやってみようせな@sena-v.comnpm install 4.39s user 3.44s vs bun install 1.65s user 1.43sすませんした(大声土下座)せな@sena-v.comここはともかくnpm scriptsまでbunに置き換える理由が思いつかんな...? ↓ npm run typecheck 3.66s bun run build 32.47s bun run typecheck 2.10s npm run build 32.75sすごいじゃん？パッケージ内の処理多寡依存っぽいかな？
検証して思ったこと
事前に懸念していたこととして相性問題みたいなものがあったが、基本的には入れ替えだけで普通に動作した。
数年前はどうだったかわからないが、メジャーどころとの相性感は問題なさそうで良かった。
とはいえそれぞれメリデメが存在するため個々のユースケースに一番あったものを取り入れていくと良い。
pnpmの良かったところ
- 共有領域参照のため、同じバージョン・ライブラリを使用する環境では大幅に時間と容量節約が可能
- npm純正よりはある程度早い、思いライブラリへの依存どんどん増えたら差が出るかも
pnpmの気になったところ
- pnpm専用領域にインストールしハードリンク参照をする関係上、初回インストールはそこまで早くない
- package.jsonにインストールされた物にしかアクセス不可なため面倒さが増える可能性あり
特に気になった点として、ハードリンク化される＝package.jsonに書かれている物にのみアクセスが可能になるため、
新規ライブラリを採用した際公式ドキュメントがpnpm前提でない場合は個別にインストールが必要となり
package.jsonの記述が場合によっては長大になり、著しく読みづらくなる可能性もありそうです。
bunの良かったところ
- npm installと比較してかなり早い(ここのメリットがかなり大きい)
- tsファイルの実行が楽(ts-node --esmのオプションを考慮しなくても動く)
bunの気になったところ
- bun.lockbがバイナリファイルのため、差分がgitでチェックしづらい(チェックはCI前提がよい)
- package-lock.json系のrenovateのようにロックファイルを参照するプラグインと相性が悪い
個人的にはpnpmに関しては現状あまり導入するメリットは感じなかった。
PCの容量についてはケチる方が悪いという考えの元強いて採用メリットがありそうな状況をあげるとしたら、
lockファイルがバイナリ形式で書き出されて欲しくない(差分が見たい)がインストール速度を上げたい、
かつimportが厳密になるのは許容できる場合には選択肢にあげてもいいかもしれないと思った。
bunに関しては速度がかなり違うのでそれだけでもかなり採用価値があると思う。
このブログに関しては上に記載したrenovateを使用してパッケージを最新化しているが、そういったケースでも
CIのinstall時にのみbun installを使用することでインストール時間削減の恩恵を受けられる。
GitHub ActionsのCI用コンテナは割と当たり外れが激しく、インストール時間が伸びることも多いため、
小技で時間削減ができる箇所はどんどん削減していくとCI実行時間が短縮されるためメリットが大きい。
まとめ
- 昔は不明だが現状相性問題はそこまで感じないため、bunやpnpmへの乗り換えは積極的にやっていきたい
- pnpmはバイナリ形式ではないlockファイルが欲しいが、install速度を少しでも早めたい場合に有用
- bunはinstall速度がかなり高速なため、特段理由がなければメイン使いしても良さそう
- CIの実行時に限定して使うという意味ではbunがかなり選択肢として良さそう
2024-03-06
- 1 -