WEBサービス創造記

WEBサービスを作ったり保守したりしてる人のメモブログです。

composerでパッケージを管理しているプロジェクトではcomposer.lockをGitの管理下に含めるべき

      2015/10/13

状況

リポジトリにcomposer.lockが含まれていないため、デプロイする際に毎回composer.jsonを生成して`composer install`(= `composer update`)が実行される。そのためデプロイ時にパッケージのバージョンアップがかかる。

この兼ね合いでローカルとデプロイ先であるステージング環境でパッケージのバージョンに差異が生じ、新しいバージョンでは当該パッケージを使用している機能が動作しなくなった。

Workaround(回避策)

※以下、Redmineからの引用

まず本件の事前知識としてcomposerの使い方が必要になりますので、composer installやupdateの振る舞いについてご説明させていただきます。
すでにご存知の事の場合は確認の意味でご覧ください。

`composer install`はcomposer.lockの内容に応じてパッケージのインストールを行います。
`composer update`は最新バージョンの依存関係を取得しcomposer.lockの内容を更新してパッケージをインストールします。

`composer install`はただcomposer.lockで指定されたバージョンのパッケージをインストールするだけなので、composer.jsonにパッケージを新しく追加した場合はcomposer.lockを更新する`composer update`を利用しないと、パッケージの新規インストールは行われません。

このプロジェクトでは「commit: 4ebfd4ad」でcomposer.lockをgitの管理下から削除しています。
`composer install`では、composer.lockが存在しない場合はバージョンの依存関係を取得した上でcomposer.lockを作成してからインストールを行います。
つまり`composer update`の実行と同義となります。

端的に言えば、現在デプロイ毎に`composer update`が走ると認識いただくとわかりやすいかと思います。

以上がcomposerの使い方と、現在プロジェクトでどのようにcomposerが使われているかです。
下記からエラーの原因の説明に入ります。

今回エラーが発生したパッケージは”proengsoft/laravel-jsvalidation”です。
デプロイを実行したのは2015/10/02 ですが、このパッケージは9/15に1.2.0にバージョンアップされています。

デプロイしたのはパッケージが1.2.0にバージョンアップされたあとなので、デプロイ時の`composer install`(実質update)でこのバージョンアップが適用されてしまいました。
結果、インストールされた1.2.0では当該パッケージを使用している機能が動作しなくなったというのが今回のエラーの経緯となります。

このようにデプロイ毎にパッケージのアップデートを走らせると意図しないエラーが発生することがあるので、composer.lockをGitの管理下に含めたほうがいいです。

composer.lockを更新してからコミットすることで、デプロイ時に`composer install`を実行しても必ずcomposer.lockで指定したバージョンしか入らなくなり、今回のようなエラーは発生しなくなります。

 - PHP , , ,