Laravel:composer のパッケージアンインストールは軽率に実行してはダメでした

Laravel:composer のパッケージアンインストールは軽率に実行してはダメでした

Laravel:composer のパッケージアンインストールは軽率に実行してはダメでした

ちょっと面白いSDKを見つけてインストール。で、使えないと判断して削除したところ、Laravel自体にエラー発生。
「grpc.soがない?」そんなわけないだろと存在するはずの場所を確認してみると…「ない」…。

作業としてやったこと

  1. 某SDKのcomposerインストール
  2. テストScript組んで動作確認
  3. 某SDKのcomposer経由での削除

これだけしかやってないので、原因は項目3の【composer remove】しか考えられない。

SDKパッケージ削除で実行したコマンド

これです。
[package]にはインストール時に指示したパッケージ名が入ります。

既存の仕組みに機能追加したいときはバックアップをしっかり採る

重要ですね、バックアップ。

ちなみに、私はこの時バックアップ採ってませんでした。
おかげで大慌て。

Dockerで作成してあるとこんな時にも便利

まぁ(幸いにも?)Dockerでの構築だったのでいろいろとやりようがあって助かりました。
こういう時にDockerのありがたみを感じるとは思わなかったですけど。

  • データはMySQLコンテナに入っているので他のコンテナを再構成しても死なない
  • DockerFileは【コンテナ起動】できる構成が入っているのでRUNすれば無くなったOSパーツは再構築できる

つまりは、OSとLaravelのコンテナをリビルドしてあげれば問題解決です。

今回の問題点

使ったコマンドが悪かったと反省しています。

SDKはいろんなパッケージを利用して構築されていることが殆どです。
そこに【composer remove [package]】だけでなく【–update-with-dependencies】を付けてしまった事が問題でした。きれいにアンインストールしようという欲が悪かった…。

「dependencies=依存関係」です。

と指示すると、一緒にインストールされた関連ファイルも道連れにしてくれます。
【便利】なんですけど、SDKに使ってはいけなかった。気づいたのは エラーを吐いたgrpc.soだけですけど、多分ほかにも持って行ったファイルあったと思います。

超反省。

まとめ

プログラミングで大抵のことできるようになったので、「一気に」とか「まとめて」とかを優先してしまうようになってるなぁと自己分析。
それが悪いとは全く思わないのですが「ちょっと考える」という時間は必要だと実感しました。

SDKのアンインストールで依存関係と一緒に処理させたらどうなるか。

少し考えればわかることですもんね。
いやぁ、いい経験になりました。