[Solved] Keeping composer.json updated and maintained

Question

You have one central, very wrong sentence:

e.g. what do i do when my composer.json says “require”: {
“php”: “>=5.3.3”,
“symfony/symfony”: “~2.4”, but downloads php 7.4 and symfony 4.3 instead? is this ok? Or do i ineed need to maintain my composer.json file?

Wrong, Composer will not install any version of PHP, but will warn you if the version used is incompatible with what is declared. It will not install packages that will not run with your installed version of PHP.

And wrong, when declaring “~2.4”, this means to not install version 3.0 and above, so this won’t install symfony 4.3 ever.

But yes, you need to maintain your composer.json. You should check at least two things periodically, maybe three:

Does your software run with the latest allowed packages? E.g. run composer update, then your test suite – it should work.
Does your software run with the lowest required versions? E.g. run composer update --prefer-lowest, then your test suite – it should work.
Does your software run with an arbitrary combination of package versions – for example with the combination recorded in the composer.lock file?

If you find any incompatibilities, you should probably try to exclude these versions.

I, too, would love to see dependencies on branches to be a thing of the past. Depending on a dev version of a release is only slightly less bad. But as long as the most common installation instruction tells the user to “require dev-master”, this won’t happen soon. The community still needs a good bit of education on why using branches is a bad thing.

I don’t think the compatibility chart you mentioned adds anything useful. There is no such thing as an optional dependency. If it is needed, it belongs into the “required” section. If it’s not needed, it is no dependency. If another package can be used together with this one, and putting them together is the task of the main application – that’s a task for the application developer to manage.

Any why cant i find a default composer.json file anywhere? it would be great to see one for each new symfony release so i can just update the top default symfony requires easily atleast…

What purpose would that have? The default composer.json probably will be created by running composer init and answering the questions, i.e. adding a name, a description, a license, a developer contact and – optionally – some dependencies. The whole point of semantic versioning is that incompatible updates are clearly marked as a major version increment, allowing you to not install them when updating. If you say that you can use Symfony version 2.3, you should expect Symfony version 2.99 to also run your application.

The problem is feature creep – you might accidentially use a compatible feature of e.g. Symfony 2.5, which would be missed in 2.3 and violate your minimum version requirement. Thats what --prefer-lowest is for in your automated tests: You should investigate if the test fails, and update your version requirements if the failure is due to lack of features in the minimum version requirement – or fix the code that incorrectly used a feature that wasn’t present in the minimum required version if that’s the goal.

Accepted Answer

You have one central, very wrong sentence:

e.g. what do i do when my composer.json says “require”: {
“php”: “>=5.3.3”,
“symfony/symfony”: “~2.4”, but downloads php 7.4 and symfony 4.3 instead? is this ok? Or do i ineed need to maintain my composer.json file?

Wrong, Composer will not install any version of PHP, but will warn you if the version used is incompatible with what is declared. It will not install packages that will not run with your installed version of PHP.

And wrong, when declaring “~2.4”, this means to not install version 3.0 and above, so this won’t install symfony 4.3 ever.

But yes, you need to maintain your composer.json. You should check at least two things periodically, maybe three:

Does your software run with the latest allowed packages? E.g. run composer update, then your test suite – it should work.
Does your software run with the lowest required versions? E.g. run composer update --prefer-lowest, then your test suite – it should work.
Does your software run with an arbitrary combination of package versions – for example with the combination recorded in the composer.lock file?

If you find any incompatibilities, you should probably try to exclude these versions.

I, too, would love to see dependencies on branches to be a thing of the past. Depending on a dev version of a release is only slightly less bad. But as long as the most common installation instruction tells the user to “require dev-master”, this won’t happen soon. The community still needs a good bit of education on why using branches is a bad thing.

I don’t think the compatibility chart you mentioned adds anything useful. There is no such thing as an optional dependency. If it is needed, it belongs into the “required” section. If it’s not needed, it is no dependency. If another package can be used together with this one, and putting them together is the task of the main application – that’s a task for the application developer to manage.

Any why cant i find a default composer.json file anywhere? it would be great to see one for each new symfony release so i can just update the top default symfony requires easily atleast…

What purpose would that have? The default composer.json probably will be created by running composer init and answering the questions, i.e. adding a name, a description, a license, a developer contact and – optionally – some dependencies. The whole point of semantic versioning is that incompatible updates are clearly marked as a major version increment, allowing you to not install them when updating. If you say that you can use Symfony version 2.3, you should expect Symfony version 2.99 to also run your application.

The problem is feature creep – you might accidentially use a compatible feature of e.g. Symfony 2.5, which would be missed in 2.3 and violate your minimum version requirement. Thats what --prefer-lowest is for in your automated tests: You should investigate if the test fails, and update your version requirements if the failure is due to lack of features in the minimum version requirement – or fix the code that incorrectly used a feature that wasn’t present in the minimum required version if that’s the goal.