How to force composer to reinstall a library?

Question

I'm using the ZF2 skeleton app and it has a .gitignore that prevents external libraries from being commited to git. While debugging I like to go and change stuff here and there in the libraries' source to learn how things work. If these were version controlled it would be very easy to revert them back to their original state.

How can I force Composer to reinstall a particular framework so that I can get a fresh -unmodified- copy again?

PS: Please don't suggest removing the .gitignore file since it's there for a reason; it prevents my third party libraries from getting into my app's repository. I can always install them during an automated deployment.

Solution 1

You can use the --prefer-source flag for composer to checkout external packages with the VCS information (if any available). You can simply revert to the original state. Also if you issue the composer update command composer will detect any changes you made locally and ask if you want to discard them.

Your .gitignore file is related to your root project (ZF2 skeleton) and it prevents the vendor dir (where your third party libs are) from committing to your own VCS. The ignore file is unrelated to the git repo's of your vendors.

Solution 2

First execute composer clearcache

Then clear your vendors folder

rm -rf vendor/*

or better yet just remove the specific module which makes problems to avoid having to download all over again.

Solution 3

I didn't want to delete all the packages in vendor/ directory, so here is how I did it:

1. rm -rf vendor/package-i-messed-up
2. composer install again

Solution 4

What I did:

1. Deleted that particular library's folder
2. composer update --prefer-source vendor/library-name

It fetches the library again along with it's git repo

Solution 5

Reinstall the dependencies. Remove the vendor folder (manually) or via rm command (if you are in the project folder, sure) on Linux before:

rm -rf vendor/

composer update -v

https://www.dev-metal.com/composer-problems-try-full-reset/

View more solutions

Comments

[vascowhite]

One option would be to delete composer.lock and then run composer install

[Julian]

Initially your -prefer-source suggestion didn't work until I realized that I had to remove and reinstall all libraries for this to work as I intended and then composer status -v gave me the info with the changes.

[Halfstop]

@Loenix, unlock them.

[okdewit]

I've had cases where the local cache was corrupted, so even after deleting the vendor directory I kept reinstalling a broken dependency. composer clearcache is a good addition in such cases.

[aarcarr]

or 'composer require vendor/package-i-messed-up' would be good too

[frederickjh]

This seems like a very radical approach considering that composer then needs to reinstall all packages when the OP just needs one package reinstalled. composer require vendor/package will do what the OP wants and in less time too. I am a bit surprised that so many have up-voted this answer.

[Neil Davis]

if composer clearcache doesn't work you can delete the /home/[username]/.cache directory. That'll force a re-download. Useful if you use private composer packagist, in addition to packagist.composer.org, and someone makes changes without adding a new tag.

[Sean the Bean]

If that doesn't work, you might run composer clearcache first in case the cache got corrupted for some reason.

[Sean the Bean]

If that doesn't work, you might run composer clearcache first in case the cache got corrupted for some reason.

[ummdorian]

Composer does not necessarily only install in the vendor directory, so even as a heavy-handed approach it does not work in all situations.

[Elijah Lynn]

This is the right way. And to clarify, it does need to be the /vendor/<vendor> that is removed for composer to reinstall it from the lock file. If one removes just the <package> directory and leaves the <vendor> named directory behind e.g. /vendor/<vendor>/<package> then it won't re-install.

[Nico Haase]

Please add some explanation to your answer such that others can learn from it - this does not look like a good solution to me, as it contains the possibility that the dependencies of other packages change

[Nico Haase]

Please share more details - why should this be an obvious answer? This changes the version dependencies, so it does not look really good to me

[Nico Haase]

composer update should not be run in this case, as this changes the dependencies

[Nico Haase]

composer update should not be run in this case, as this changes the dependencies

[Attila Fulop]

@NicoHaase only if -w, --with-dependencies or -W, --with-all-dependencies argument is passed to composer.

[Nico Haase]

No, even ` composer update vendor/library-name` will update that library instead of resetting it to the version that was installed before modifying the sources

[Attila Fulop]

@NicoHaase the library itself might be updated (in composer.lock) based on the given version constraints defined in composer.json. But not the dependency tree.

[Yevgen]

@NicoHaase it seems obvious because it is built in composer command, but you have a point. I updated answer.

[Nico Haase]

Why not remove the vendor folder and run composer install instead? What's the point in removing and reinstalling the package after all?

[Ilya Kolesnikov]

I've added explanations as much as possible. These commands are native by Composer and recommended by SO community. If you need some more explanations please write what exactly do you want to see, I'll try to answer

[Nico Haase]

Is there any good reason not to call composer install after removing the package's folder from the vendor directory? This would skip all unneccessary changes in the lock file

[Yevgen]

@NicoHaase I assume that need to re-install one package arises when you are developing package / working on it. In this case you can hardly screwed up with version compatibility. This is why I don't share your worries. Advantages are: 1) Re-installing one package usually faster then reinstalling all of them 2) If I need to make it multiple times I can lose concentration so I don't want to rm -rf around when it is not mandatory.

[Ilya Kolesnikov]

Removing vendor directory is not a native action, composer remove is a command that makes to remove one package, composer require - to install it Editing anything like composer.json, composer.lock, /vendor manually is bad practice Removing whole folder is slow and unnecessary Before you will be able to make composer install for new version of package, you'll need to edit composer.json which is bad practice if you do it in "require" section Do you have any proofs that manually removing folders better than reinstalling one package by native composer commands?

[Nico Haase]

"Proofs"? No. But do you have any proofs that reinstalling does install the very same version of that package that was used before?

[Ilya Kolesnikov]

Proof is not a best word here If you need a specific version of a package you can explicitly indicate it you can do it by specifying tag, branch or even revision number, so if you'll use revision number or tag, it will be exactly same version as it was before. Мy answer is actually better suited for cases where you for some reason need to install a different version of a package in place of the old one. The reason could be when you developing a package or a fork

[hakre]

This has been answered in stackoverflow.com/a/67882743/367456 already.