お前は誰の回しもんや？
どこの世界・界隈にも、熱狂的な信者はいるもので、様々なSNSで布教活動が日々繰り広げられているかと。
やれVimが最高だの、Emacsが至高だの、VSCodeが１番だの、Eclipseはクソだの、Cが最強だの、JQueryなんて時代遅れだのなんだのと、
一体お前はどこの回しもんだ？
ただ単に新しい技術に乗れなかったから古い技術を推してるんじゃないのか？
単純に流行に乗ってコレが１番だと言いたいだけなんじゃないか？
と、思いつつツール・技術選定に役立たせていただいております（誠に有難うございます
どうもとりあえず流行に乗ればいいんでしょ？なえ～すけさんです。
まぁ今回もpnpmのユルイ布教活動ですが、どうぞ読んでいってね！
node_modulesにいるアレ
Node開発をしている初心者やNodeなんとなく使ってる勢はこんなことを思うのでは無かろうか。
なんでこのライブラリ入ってるんだ……？
package.jsonには書いてない。
でもnode_modulesにはいる。
そうだね、
npm installすると依存するアレも一緒に入ってきちゃうアレだね（ｴﾋﾞﾊﾞﾃﾞｨﾊﾟｯｼｮﾝ
そんなときの pnpm why
例えばlodashを調べたい場合
pnpm why lodash
すると
project
└─ packageA
└─ lodash
みたいに
「誰が依存しているのか」 を追跡できるわけで。
地味だけどめちゃくちゃ便利
特に便利なのがこの辺。
① 謎ライブラリ調査
気づいたら増えてる謎package。
pnpm why left-pad
すると
「あー、お前経由か」
が分かる。
→node_modules探検隊をしなくて済むね
② 脆弱性調査
npm auditで
critical vulnerability
とか出たとき。
まず思う。
「いや誰が使ってんの？」
そんなときには
pnpm why minimist
これで依存元を特定できる。
③ package削除できるか確認
dependencies整理してると
「これ消して大丈夫か？」
となる。
そんなときも
pnpm why axios
で確認できる。
④ monorepoで真価を発揮する
workspace構成だと特に便利。
apps/frontend
apps/backend
packages/shared
みたいな構成で
「どこが依存してるんだっけ？」
を即確認できる。
npmにもあるけど、pnpmは見やすい
npmにも npm why はあるけど、個人的には
pnpmのほうが依存関係がかなり追いやすい
実際かなり助かる場面
地味に多いのがこれかなと
package消したのに容量減らない
調べたら別package経由でまだ使われてた みたいなケース。
まとめ
実務で余り使う機会は少ないかも知れませんがpnpm why は
- 謎ライブラリ調査
- 脆弱性対応
- dependencies整理
- monorepo管理
この辺でかなり役立つかなと。
※特にNPMから移行するとかになった時に消していいか迷うようなケースが有る場合
Node開発を長くやっていると、
「誰が選定したのか記憶にない、なんで入ってるか分からないライブラリ」
が少しずつ増えていく。
そして数ヶ月後。
誰も理由を説明できなくなる。
そうなる前に、ちゃんと依存関係を把握しておくと後で混乱しなくていいのかななんて思ったり思わなかったり。