Vendoring: Should we do it?

We recently had an interesting discussion with one of our clients about one of its habits:

Vendoring?

That means committing the dependencies of your project with your code.
I was quite surprised at the beginning because i thought it was a wrong practice from a bygone time.
But then I discovered that there are many projects that commit the dependencies folder to their git repository.

Why you should not commit vendor?

First of all, the official Composer recommendation is not to commit vendor.
But we will talk about committing vendor in our vision.

Heavy repository

For example, my actual project goes from 50 MB to 300 MB.
This brings problems with indexing (IDE) taking too much time, and also downloading the repository can become a problem.

Conflict problem

If we push multiple merge requests that update the vendor folder, we can generate unnecessary conflicts.
It will be difficult to resolve those conflicts or to check differences between versions.

Confused Git

Committing vendor will confuse Git, because a large number of libraries did not ignore the git folder inside them, so Git will show these libraries as sub-modules without them being real sub-modules.

ENV problems

If we commit vendor, we will face a problem when switching between environments.
For example, if each (dev, preprod and prod) environment has its specific requirements then we will have unneeded libraries or we will lack needed libraries.

Dependencies history and composer cache

The composer.lock file will not match the dependencies.
Duplicated history can be found and the reference will not match the installed packages.

"reference": "e495f5c7e4e672ffef4357d4a4d85f010802f940"

"time": "2020-09-02T16:23:27+00:00"

This makes composer.lock unusable.

In this case, the vendor will be created using a specific composer inside a specific environment.
So we will not have the possibility of updating or maintaining the dependencies folder on the destination server.

At the end, it will be much more difficult to have a clear vision of your dependencies and their state.

Dependency become malware

How we can discover that a dependency is a malware or inject a malware? There is no way if we don’t use Composer frequently.

Conclusion

There are some people that consider vendoring as the solution of many build problems, but we can find more appropriate and professional solutions for the exact same problems:

• Vendoring can make the deploy / build in our CI faster but using Composer cache do the same.
• Vendoring can ensure exact version of our dependencies but cache and repeatable build using composer.lock with the exact versioning can do the same.
• Vendoring can avoid malware in some cases but using Composer cache and audit can do it even better.
• Vendoring can make build independent of the internet but Composer proxy and cache can do the same.
  Also, we can mirror all dependencies in our custom repository, then we can centralize all projects.

Globally speaking, both systems have pros and cons, but to fix the vendoring ones is more complicated, less clean and less effective than adjusting the use of Composer.

Notice

Composer 2 can be a possible and effective solution for many problems, it can make build faster, secured and more robust.