我应该在作曲家提取的供应商文件夹中检入库吗？

Question

I've already spent a few hours searching for an answer to my question but still haven't found a suitable answer.

Basically, I've taken over a PHP project which uses composer to pull in third party libraries/dependencies. However, a lot of the dependencies are no longer managed and is possible that the author might remove them completely from github anytime.

I'm currently thinking that I should check in the whole vendor folder so even if the libraries are no longer available through composer, I will still have them with me.

Alternatively, I could fork those libraries repo and have composer to pull from my account instead. Is this acceptable?

I would really hope to get some advice on the best method to deal with this.

Thanks in advance!

Answer 1

Should i check in the whole vendor folder in, so even if the libraries are no longer available through composer, I will still have them with me?

My suggestion is to create a backup branch containing your application with all it's vendors. Just do a git checkout -b {VERSION}-backup , followed by composer install (which gets you the composer.lock and all dependencies into the defined vendor folder) and then a git push origin {VERSION}-backup .

This allows to rely on dynamic package management as long as the packages are available via Packagist and downloadable from their source (Github, etc.). Now, in case, a dependency gets deleted and becomes un-available, you remove it from your composer.json and merge the code from the last {VERSION}-backup branch into the master branch. = You replaced a dynamic dependency with a static one from you backup.

By the way: ever thought about getting a security audit for your code? This will not work, with dynamically pulled dependencies. Security audits are done for specific versions - for a static set of dependencies. Given this context, pushing in a complete app with all it's dependencies is common and a best-practice. But what do we have: Composer in the backend to install new themes and composer install --no-dev --optimize-autoload on the production box to "install" software. Modern times ;)

Could I fork those libraries repo and have composer to pull from my account instead. Is this acceptable?

Yes! And you might also ask the guys over at Packagist to remove no-longer maintained packs or get them replaced or aliased to a new personal fork.

Answer 2

It really depends on whether your project needs to be optimized for portability or not. Although, it's better safe with a best-practice violation, than sorry with an unavailable dependency you have to spend time replacing and refactoring for ...

Answer 3

From her packagist - theoretically it is possible but unlikely. From the practice the main problem with packages directly connected to CVS. But if it is live project you allays can find another copy of code to recover functional.