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!
Top comments (10)
I never add dependencies to the version control, only the lock files.
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.
Similar to what other non-PHP folks have said, in Ruby world the actual gem code would not typically land itself in version control.
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.
Also composer has a composer.lock file.
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. Whencomposer.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.
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.
See also: theregister.co.uk/2016/03/23/npm_l...
Thanks for the comments all.
Sorry, I didn't see your post when I posted mine, so here it is:
He Commits Vendor! 😱
🇫🇷 Boris Jamot