How to Downgrade or Install a Specific Version of Composer

How to downgrade or install a specific version of Composer?

Assuming a regular composer installation, to rollback to version 1 of composer, you simply execute:

composer self-update --1

When you want to go back to version 2 (which you should, after updating or removing the incompatible plugins):

composer self-update --2

---

The above will take you to the latest on any of the two major versions.

You can also "update" to a specific version just by passing the version number to self-update:

composer self-update 1.10.12
composer self-update 2.0.7

After performing any self-update, you can specify --rollback to go back to the previously installed version.

composer self-update
composer self-update --rollback

Finally, if you are feeling adventurous, you can update to a pre-release version by executing:

composer self-update --preview

How to install old version of composer

These commands will install composer binary in composer.phar file in current working directory. You may try to verify this by running php composer.phar -v command. composer command will most like point to some global installation in your system - you need to move new binary to correct place, so it could be recognized as global command (see docs):

mv composer.phar /usr/local/bin/composer

---

If you have already Composer installed, you should able to use self-update command to downgrade to any version:

composer self-update 1.4.1

or

sudo -H composer self-update 1.4.1

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

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.

---

Related Topics