[GH-ISSUE #195] composer.lock not present

kerem commented

2026-02-26 09:36:21 +03:00

Owner

Originally created by @lenada on GitHub (Jun 6, 2016).
Original GitHub issue: https://github.com/opensolutions/ViMbAdmin/issues/195

Please commit the composer.lock file to precisely pin the dependencies.
In the release notes of 3.0.15 it is recommended to run composer update which probably works but is not a good practice.
If the composer.lock was present the updated version of opensolutions/OSS-Framework would be reflected there (developers should run composer update not "users") - would also mean a code change for 3.0.15.
The end user would then run composer install to exactly install the dependencies that are described in the lock file.

Should I send a PR?

Originally created by @lenada on GitHub (Jun 6, 2016). Original GitHub issue: https://github.com/opensolutions/ViMbAdmin/issues/195 Please commit the `composer.lock` file to precisely pin the dependencies. In the release notes of 3.0.15 it is recommended to run `composer update` which probably works but is not a good practice. If the composer.lock was present the updated version of `opensolutions/OSS-Framework` would be reflected there (developers should run composer update not "users") - would also mean a code change for 3.0.15. The end user would then run `composer install` to exactly install the dependencies that are described in the lock file. Should I send a PR?

kerem closed this issue

2026-02-26 09:36:22 +03:00

kerem commented

2026-02-26 09:36:22 +03:00

Author

Owner

@PhrozenByte commented on GitHub (Jun 7, 2016):

Adding the composer.lock has various disadvantages - the most important is, that users don't receive (possibly security critical) updates of dependencies. That's the reason why ViMbAdmin uses version constraints like ~1.12 and not e.g. 1.12.2. Especially for projects which release versions rather infrequent (like ViMbAdmin) is this nothing to sneeze at...

The mentioned example with opensolutions/OSS-Framework could have been solved better: tag new releases (it's your repo) and use version constraints. The latest security update in OSS-Framework should have been released as v1.0.1 and ViMbAdmin's composer.json should reflect this with a version constraint like ~1.0.1 or ^1.0.1 (depending on the use of semantic versioning). Sure, the README.md of opensolutions/OSS-Framework states that the project "is only currently maintained for bug/security fixes", but this shouldn't be an obstacle to tag new bug/security releases...

And the most important last: Without a hint that users must run composer update (as it is also stated in the Updates article of ViMbAdmin's wiki...) on their own they will never receive the updated dependencies, no matter whether composer.lock has been commited or not! composer.lock has absolutely nothing to do with that!

@barryo @lenada

@PhrozenByte commented on GitHub (Jun 7, 2016): Adding the `composer.lock` has various disadvantages - the most important is, that users don't receive (possibly **security critical**) updates of dependencies. That's the reason why ViMbAdmin uses version constraints like `~1.12` and not e.g. `1.12.2`. Especially for projects which release versions rather infrequent (like ViMbAdmin) is this nothing to sneeze at... The mentioned example with `opensolutions/OSS-Framework` could have been solved better: tag new releases (it's your repo) and use version constraints. The latest security update in OSS-Framework should have been released as v1.0.1 and ViMbAdmin's `composer.json` should reflect this with a version constraint like `~1.0.1` or `^1.0.1` (depending on the use of semantic versioning). Sure, the `README.md` of `opensolutions/OSS-Framework` states that the project "is only currently maintained for bug/security fixes", but this shouldn't be an obstacle to tag new bug/security releases... And the most important last: Without a hint that users must run `composer update` (as it is also stated in the Updates article of ViMbAdmin's wiki...) on their own they will **never** receive the updated dependencies, no matter whether `composer.lock` has been commited or not! `composer.lock` has **absolutely nothing to do with that!** @barryo @lenada

kerem commented

2026-02-26 09:36:23 +03:00

Author

Owner

@barryo commented on GitHub (Jun 7, 2016):

@PhrozenByte - on foot of this issue, I reviewed the documentation at https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file - which clearly states:

Commit your application's composer.lock (along with composer.json) into version control.

So:

Without a hint that users must run composer update (as it is also stated in the Updates article of ViMbAdmin's wiki...) on their own they will never receive the updated dependencies, no matter whether composer.lock has been commited or not!

If the documentation can be made clearly, please - by all means - update it.

@barryo commented on GitHub (Jun 7, 2016): @PhrozenByte - on foot of this issue, I reviewed the documentation at https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file - which clearly states: > **Commit your application's composer.lock (along with composer.json) into version control.** So: > Without a hint that users must run composer update (as it is also stated in the Updates article of ViMbAdmin's wiki...) on their own they will never receive the updated dependencies, no matter whether composer.lock has been commited or not! If the documentation can be made clearly, please - by all means - update it.

kerem commented

2026-02-26 09:36:23 +03:00

Author

Owner

@PhrozenByte commented on GitHub (Jun 7, 2016):

ViMbAdmin's documentation is fine, this was just for @lenada's false statement that commiting the composer.lock changes anything regarding the necessity that users must run composer update on their own.

I know that the composer docs state that composer.lock should be commited, but as I've explained, this is a really bad idea for infrequently updated projects like ViMbAdmin, as it can (and will in the long-term) lead to insecure installations. Trust your dependencies (also refer to this excellent SO answer of Josh Johnson)!

If you know that one of the projects you depend on doesn't care about BC, pin your dependency to a exact version in your composer.json, but don't let this affect other projects which ensure BC in an exemplary manner (like Zend or Doctrine).

@PhrozenByte commented on GitHub (Jun 7, 2016): ViMbAdmin's documentation is fine, this was just for @lenada's false statement that commiting the `composer.lock` changes anything regarding the necessity that _users_ must run `composer update` on their own. I know that the composer docs state that `composer.lock` should be commited, but as I've explained, this is a really bad idea for infrequently updated projects like ViMbAdmin, as it can (and _will_ in the long-term) lead to insecure installations. Trust your dependencies (also refer to [this excellent SO answer of Josh Johnson](http://stackoverflow.com/a/21589454))! If you know that one of the projects you depend on doesn't care about BC, pin your dependency to a exact version in your `composer.json`, but don't let this affect other projects which ensure BC in an exemplary manner (like Zend or Doctrine).

kerem commented

2026-02-26 09:36:23 +03:00

Author

Owner

@lenada commented on GitHub (Jun 7, 2016):

@barryo thank you, very much appreciated.

@PhrozenByte running composer update in production environments is a no go.
Also with automated deployments/builds composer update is not controllable.
Another issue is reproducibility of "bugs" users might encounter - when dependencies are not exactly pinned by a composer.lock hunting them down can become a nightmare.

I don't think this is about trust ( I have experienced bc breaks with doctrine and zf2 (minor releases) although they are trying to stick to semver and have excellent test-coverage).

@lenada's false statement that commiting the composer.lock changes anything regarding the necessity that users must run composer update on their own.

Once a new release is tagged users should run composer install to install the exact dependencies the release. If you personally want and consider it a good practice you can still composer update.

@lenada commented on GitHub (Jun 7, 2016): @barryo thank you, very much appreciated. @PhrozenByte running `composer update` in production environments is a no go. Also with automated deployments/builds composer update is not controllable. Another issue is reproducibility of "bugs" users might encounter - when dependencies are not exactly pinned by a composer.lock hunting them down can become a nightmare. I don't think this is about trust ( I have experienced bc breaks with doctrine and zf2 (minor releases) although they are trying to stick to semver and have excellent test-coverage). > @lenada's false statement that commiting the composer.lock changes anything regarding the necessity that users must run composer update on their own. Once a new release is tagged users should run `composer install` to install the exact dependencies the release. If you personally want and consider it a good practice you can still `composer update`.

kerem commented

2026-02-26 09:36:23 +03:00

Author

Owner

@PhrozenByte commented on GitHub (Jun 7, 2016):

Everywhere else it's common sense to rely, i.e. trust on dependencies. A Linux distribution won't work if arbitrary software would rely on specific patch releases (i.e. 1.0.3). They all depend on minor releases (i..e. 1.0.x) and trust the Maintainer of dependent software that they don't release patch versions which break BC. That's how dependency management works - everywhere else at least. Security is much more important than the vague possibility of dependencies breaking BC.

Once a new release is tagged users should run composer install to install the exact dependencies the release.

This is probably just a misunderstanding. You must run composer manually - always. Just commiting composer.lock doesn't let composer magically know that the composer.lock has been changed after updating ViMbAdmin.

@PhrozenByte commented on GitHub (Jun 7, 2016): Everywhere else it's common sense to rely, i.e. trust on dependencies. A Linux distribution won't work if arbitrary software would rely on specific patch releases (i.e. `1.0.3`). They all depend on minor releases (i..e. `1.0.x`) and trust the Maintainer of dependent software that they don't release patch versions which break BC. That's how dependency management works - everywhere else at least. Security is much more important than the vague possibility of dependencies breaking BC. > Once a new release is tagged users should run composer install to install the exact dependencies the release. This is probably just a misunderstanding. You must run `composer` manually - always. Just commiting `composer.lock` doesn't let `composer` magically know that the `composer.lock` has been changed after updating ViMbAdmin.

Rows
Columns

[GH-ISSUE #195] composer.lock not present #155