楽しいpnpmライフだったはずなのに
どうも、え～すけさんですよ。
この記事からpnpmを使いだして、PCの容量がアホほど軽くなったけど、色々とヤッていたお話。
マジで何の参考にもならないかも知れないけど、笑ってやってくれればいいと思うよwww
導入作業
既存のプロジェクトをpnpmにしようと、
とりあえずnode_modulesとpackage-lock.jsonを一旦ぶち消して、
pnpm installを流したんだ。
そう、ココまでは順調だったんだ（まだ出だしだけど。。。
動作確認
さてinstallも終わったから、試しに動かしてみたところ。。。
Module not found
は？ちょっと、何言ってるかわからない（理解してるが、納得してない
アレか？もしかして既存バグがあったから動かないとかいうアレか？
もしくはpnpm installでも落とせない変なライブラリ使ってたっけ？
みたいな疑心暗鬼から、別フォルダにプロジェクトごとコピってnpm installを実行し、そのまま動作確認をしてみたところ普通に動くと言うね。。。
もうね、ひとり宇宙猫状態ですよ🐱
原因
ザックリ言うと、
npm時代に“たまたま動いていた”だけだった
まぁ詳細を以下に書くけど、如何にnpmやyarnって【イイカンジ】にヤッてくれてたんだなと言うことがよく分かる感じでした。
そもそもpnpmは依存解決が厳しい
例えばこういう構成
app
└─ packageA
└─ lodash
packageAと濁してますが、要はnpm install packageAをした感じね。
で、packageAはlodashに依存してるよって言うアレね。
このとき、app側でlodashをpackage.jsonに書いていなくても、npmだと参照できてしまうケースがある。
要は、package.jsonに書いていないのに、nodo_modulesになんかいっぱいフォルダが出来ていて、それらをappから参照できちゃうアレね。
pnpmは依存を厳密に分離するみたいなので、
import _ from 'lodash';
していても、package.jsonに書いてなければ普通に怒られる。
まぁコレだけのことなんだけど。。。
pnpmは面倒？？？
違う違う、そうじゃない。
面倒なのではなく
今までの依存管理が雑だった
実際に良かったこと
package.jsonが正しくなる
不要な依存や不足が見える。
チーム開発が安定する
環境差異が減る。
CIで事故りにくい
ローカルだけ動く問題が減る。
敵「npmなら動くのに。。。」
うん、その通りだね（ｳﾙｾｪ
ただそれは
壊れていることに気づいていないだけ
まとめ
- pnpmは厳しい
- でもその厳しさが逆に安全
- 「動く」ではなく「正しく動く」に近づく
最後に
pnpmに変えた直後は、今まで見えていなかった問題が急に出てくるから、たぶん少しイラつくかも知れない。
でもそれは
pnpmが壊したのではなく、元々壊れていたものを見えるようにしただけ
だと思うようにすれば、正しいコードに近づく一歩なのかなと。
いや、別にnpmやyarnを悪く言うわけじゃなくて、あっちはあっちで時間も容量も喰うけどスタンダードだし、イイカンジに緩いのでPCの容量に余裕が有るんだったら、無理にpnpmを使わずにそのままnpmで突き進めばいいじゃんって感じよ（元も子もない