Return to Answer

After doing it both ways for a few projects my stance is that composer.lock should not be committed as part of the project. I know that it is easier to do so but please bear with me while I make a case for this.

composer.lock is build metadata which is not part of the project. The state of dependencies should be controlled through how you're versioning them (either manually or as part of your automated build process) and not arbitrarily by the last developer to update them and commit the lock file.

If you are concerned about your dependencies changing between composer updates then you have a lack of confidence in your versioning scheme. Versions (1.0, 1.1, 1.2, etc) should be immutable and you should avoid "dev-" and "X.*" wildcards outside of initial feature development.

Committing the lock file is a regression for your dependency management system as the dependency version has now gone back to being implicity defined.

Also, your project should never have to be rebuilt or have its dependencies reaquired in each environment, especially prod. Your deliverable (tar, zip, phar, a directory, etc) should be immutable and promoted through environments without changing state.

Edit: I knew going in that this wouldn't be a popular answer, but if you downvote would you be kind enough to provide a reason in the comments that points out the flaw in the answer? Thanks!

After doing it both ways for a few projects my stance is that composer.lock should not be committed as part of the project.

composer.lock is build metadata which is not part of the project. The state of dependencies should be controlled through how you're versioning them (either manually or as part of your automated build process) and not arbitrarily by the last developer to update them and commit the lock file.

If you are concerned about your dependencies changing between composer updates then you have a lack of confidence in your versioning scheme. Versions (1.0, 1.1, 1.2, etc) should be immutable and you should avoid "dev-" and "X.*" wildcards outside of initial feature development.

Committing the lock file is a regression for your dependency management system as the dependency version has now gone back to being implicitly defined.

Also, your project should never have to be rebuilt or have its dependencies reacquired in each environment, especially prod. Your deliverable (tar, zip, phar, a directory, etc) should be immutable and promoted through environments without changing.

After doing it both ways for a few projects my stance is that composer.lock should not be committed as part of the project. I know that it is easier to do so but please bear with me while I make a case for this.

composer.lock is build metadata which is not part of the project. The state of dependencies should be controlled through how you're versioning them (either manually or as part of your automated build process) and not arbitrarily by the last developer to update them and commit the lock file.

If you are concerned about your dependencies changing between composer updates then you have a lack of confidence in your versioning scheme. Versions (1.0, 1.1, 1.2, etc) should be immutable and you should avoid "dev-" and "X.*" wildcards outside of initial feature development.

Committing the lock file is a regression for your dependency management system as the dependency version has now gone back to being implicity defined.

Also, your project should never have to be rebuilt or have it's dependencies reaquired in each environment, especially prod. Your deliverable (tar, zip, phar, a directory, etc) should be immutable and promoted through environments without changing state.

Edit: I knew going in that this wouldn't be a popular answer, but if you down vote would you be kind enough to provide a reason in the comments that points out the flaw in the answer? Thanks!

After doing it both ways for a few projects my stance is that composer.lock should not be committed as part of the project. I know that it is easier to do so but please bear with me while I make a case for this.

composer.lock is build metadata which is not part of the project. The state of dependencies should be controlled through how you're versioning them (either manually or as part of your automated build process) and not arbitrarily by the last developer to update them and commit the lock file.

If you are concerned about your dependencies changing between composer updates then you have a lack of confidence in your versioning scheme. Versions (1.0, 1.1, 1.2, etc) should be immutable and you should avoid "dev-" and "X.*" wildcards outside of initial feature development.

Committing the lock file is a regression for your dependency management system as the dependency version has now gone back to being implicity defined.

Also, your project should never have to be rebuilt or have its dependencies reaquired in each environment, especially prod. Your deliverable (tar, zip, phar, a directory, etc) should be immutable and promoted through environments without changing state.

Edit: I knew going in that this wouldn't be a popular answer, but if you downvote would you be kind enough to provide a reason in the comments that points out the flaw in the answer? Thanks!

After doing it both ways for a few projects my stance is that composer.lock should not be committed as part of the project. I know that it is easier to do so but please bear with me while I make a case for this.

composer.lock is build metadata which is not part of the project. The state of dependencies should be controlled through how you're versioning them (either manually or as part of your automated build process) and not arbitrarily by the last developer to update them and commit the lock file.

If you are concerned about your dependencies changing between composer updates then you have a lack of confidence in your versioning scheme. Versions (1.0, 1.1, 1.2, etc) should be immutable and you should avoid "dev-" and "X.*" wildcards outside of initial feature development.

Committing the lock file is a regression for your dependency management system as the dependency version has now gone back to being implicity defined.

Also, your project should never have to be rebuilt or have it's dependencies reaquired in each environment, especially prod. Your deliverable (tar, zip, phar, a directory, etc) should be immutable and promoted through environments without changing state.

After doing it both ways for a few projects my stance is that composer.lock should not be committed as part of the project. I know that it is easier to do so but please bear with me while I make a case for this.

composer.lock is build metadata which is not part of the project. The state of dependencies should be controlled through how you're versioning them (either manually or as part of your automated build process) and not arbitrarily by the last developer to update them and commit the lock file.

If you are concerned about your dependencies changing between composer updates then you have a lack of confidence in your versioning scheme. Versions (1.0, 1.1, 1.2, etc) should be immutable and you should avoid "dev-" and "X.*" wildcards outside of initial feature development.

Committing the lock file is a regression for your dependency management system as the dependency version has now gone back to being implicity defined.

Also, your project should never have to be rebuilt or have it's dependencies reaquired in each environment, especially prod. Your deliverable (tar, zip, phar, a directory, etc) should be immutable and promoted through environments without changing state.

Edit: I knew going in that this wouldn't be a popular answer, but if you down vote would you be kind enough to provide a reason in the comments that points out the flaw in the answer? Thanks!