CODEWITHSUNDEEP
composer-php
Matteo B.
Matteo B.

Reputation: 4074

How to get composer to install older version of a specific dependency within required range?

In my composer.json file I like to list all compatible versions of the (example) package x/y as possible in the require section. Typically that would look like "x/y": "8-10". If I execute composer install, composer of course installs the newest available version of x/y which is 10.x and that is fine, almost always. But sometimes I want to install version 8 of x/y just to check that execution of my application is still possible with version 8.

Another scenario is when a client reports a bug and has version 2.10.4 of some example/dependency whereas the newest would be 2.14.2. The example/dependency is not required by my application directly but transitively by x/y. So I just for a moment want to install my whole dependency tree with version 2.10.4 of example/dependency to debug it with that version of the library.

Of course a temporary modification of the composer.json so that it requires these exact versions would work but that approach seems unnatural, complex, and implies the risk of accidentally committing the modified composer.json to version control and thereby creating a huge mess.

I thought about modifying the composer.lock because accidentally committing a modified version of that wouldn't really cause a problem. But is it okay/recommended to modify the composer.lock file for such purposes?

Ideally I would want a command line argument that fixes some library to some version just for one execution of the composer install command without modifying composer.json.

Upvotes: 5

Views: 5103

Answers (1)

yivi
yivi

Reputation: 47613

Since install is meant to read from a lockfile, this option wouldn't make sense for the command.

But for update (and if there is no lockfile, install behaves as update), there is the --prefer-lowest flag (docs).

There is also the option to downgrade a specific package without affecting your composer.json file, by running something like:

composer update --with vendor/package:2.0.1

Mind you, any of these options will modify your lockfile, so after testing you would probably need to git restore composer.lock to go back to the original state.

Commiting a lockfile for a project by mistake should be a biggish issue. Since applications are usually built/deployed by reading the lockfile, a lockfile in an inconsistent state could break things in unexpected places.

But warding of commiting and pushing changes by mistake seems to be excessive, IMO. Developers can make changes to any file, and if they commit those "by mistake", things can break all around.

Expecting a basic "I should look what's changed before staging and commiting" seems a very low bar to me.

Upvotes: 6

Related Questions