DEV Community

loading...

Should you commit your /vendor folder to git?

Tom Metcalfe
Bristol based Drupal developer working remotely for Reason Digital in Manchester @blwd_uk.
・1 min read

The recommendation from Composer is NOT to commit your /vendor folder and have your deployment process take care of running composer install to grab all your dependancies.

I'm coming round to the school of thought that having your /vendor folder in git has some pretty big advantages after reading this article:

https://www.codeenigma.com/build/blog/do-you-really-need-composer-production

I'm curious to see if anyone else thinks this is a good idea!

Discussion (10)

Collapse
orkon profile image
Alex Rudenko

I never add dependencies to the version control, only the lock files.

https://pics.me.me/sun-neutron-star-black-hole-node-modules-heavy-objects-19525451.png

Collapse
penderis profile image
Keith

I do it when I do not have access to composer on the server then I sync ftp with the git repo because that easier in the long run that making a zip the whole time especially if the project will be running for a bit. only had to do it a few times but was worth the hassle.

Collapse
ben profile image
Ben Halpern

Similar to what other non-PHP folks have said, in Ruby world the actual gem code would not typically land itself in version control.

Collapse
rhymes profile image
rhymes • Edited

Don't know anything about the PHP world but they might both right approaches and both wrong: it depends on "reproducibility" and the platform.

Most tools now (npm 5, yarn, pipenv, bundler) have a side "lock" file which allows repeatable installations. If you configure them correctly you can be 100% sure that what you have installed in your development environment is the same in staging and production.

Committing vendor seems to make sense at first but (for example) if you develop on OSX and deploy on Linux (as many do) and you have libraries compiled against your own environment you might not be able to reproduce the build, even with the committed vendor.

So, if PHP/Composer allows you to have reproducible installs then remove the vendor, otherwise go for it (or find better tooling :D).

Another option is to use docker so you can just make an image of your environment and be sure it's the same on the server too.

Collapse
slackerzz profile image
Lorenzo

Also composer has a composer.lock file.

Collapse
aleksikauppila profile image
Aleksi Kauppila

I don't commit vendor. I don't commit any code that i'm not going to be maintaining myself. composer install generally installs all dependencies only once in an environment. When composer.json is updated it's only the updated dependencies that are going to be downloaded and applied.

As always with external dependencies it's good idea to protect yourself by creating adapters to be better prepared if you need to replace a dependency.

Collapse
weswedding profile image
Weston Wedding

It's not typical to include dependencies in a repo, but I totally am down with doing it once you're starting to worry about deployment builds.

Ooops, npm or a specific npm module doesn't exist anymore in 2025. Guess this legacy program with the security flaw in it just needs to be completely rewritten now.

Collapse
weswedding profile image
Weston Wedding
Collapse
tommym9 profile image
Tom Metcalfe Author

Thanks for the comments all.

Collapse
biros profile image
Boris Jamot ✊ /

Sorry, I didn't see your post when I posted mine, so here it is: