Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the best practice for handling composer abandoned packages?

When I run composer updates I'll occasionally get messages that packages are abandoned and I should use a different one instead, like Package webflo/drupal-core-require-dev is abandoned, you should avoid using it. Use drupal/core-dev instead. I don't have experience with Composer so I'm curious as to what is seen as the best practice for replacing outdated packages.

Where do these messages come from? I'm unsure if the source is always reliable.

like image 237
AndyReifman Avatar asked Dec 30 '19 22:12

AndyReifman


People also ask

What is composer minimum stability?

An alternative is to set your minimum-stability to dev, but tell composer you want to use stable whenever possible: "minimum-stability": "dev", "prefer-stable" : true. This basically means it will always use stable UNLESS there is no way to install a stable dependency, and therefore use dev.

What is a composer Metapackage?

metapackage: An empty package that contains requirements and will trigger their installation, but contains no files and will not write anything to the filesystem. composer-plugin: A package of type composer-plugin may provide an installer for other packages that have a custom type.

How do I update all composer packages?

To update your packagesNavigate to the root of your git repo, where your composer. json file is. Run composer update (on your local machine) to update the required packages and re-generate a composer.


1 Answers

I think the best practice is quite clear from the message "you should avoid using it". How/When to do this is not as clear. Abandoned packages will not receive updates, but composer will not be able to tell you how difficult it will be to transition to the recommended alternative. It might be that all you have to do is replace the package, because it was only a name change or having to modify your code as well.

In your case webflo/drupal-core-require-dev only contains a composer.json and the required packages match with what the alternative drupal/core-dev provides. That means replacing the package should be as easy as changing the name in your composer.json and then do a composer update drupal/core-dev.

For packages where the answer is not as straightforward, you have to rely on automated/manual tests to see if everything still works. Static code analysis tools might help as well. You will have to set them up before you do the change, so that you can see how their output differs and fix the new issues that come up.

You should do the switch to the new dependency as early as possible. Leaving it in will likely cause more work in the future when replacing it and might pose a security risk (if it is outdated and insecure). I understand that this is not always possible and using something like roave/security-advisories to tell you when there are known security issues in a package might help postponing it and giving some sense of security.

like image 90
dbrumann Avatar answered Oct 17 '22 05:10

dbrumann