4 ms·

> Don't store your vendor directory in Git! Completely unnecessary and waste of 47MB. I find that it simplifies versioning as well as making it so you don't ha

by elwell 13y ago

> Don't store your vendor directory in Git! Completely unnecessary and waste of 47MB. I find that it simplifies versioning as well as making it so you don't have to download individual dependencies. What is your suggestion otherwise?

SEJeff 13y ago
If you must... use submodules.
meritt 13y ago
That's what composer is for
- markdown 13y ago
  what is composer, and why do I have to learn it if it is completely unnecessary?
  - sexmonad 13y ago
    What is <insert technology>, and why do I have to learn it if <insert worse technology> is sufficient?
  - ianhawes 13y ago
    Composer is the de facto PHP package manager, and it is highly recommended for modern PHP applications.
Tomdarkness 13y ago
There is a composer.json and composer.lock file in the repository. All you'd need to do to download all the dependencies is have composer installed and run "composer install".
- MichaelGG 13y ago
  Thus making your application build process require full Internet connectivity, and making it require that every dependency hosting site is working. Committing dependencies is a solid decision to avoid taking a dependency on a bunch of third parties.
  - lstamour 13y ago
    "application build process" or simply the checkout process? I'd suggest your deployment process shouldn't include a public git repo others can change. Instead, use your own fork on Github, or alternatively host a git repo local to your deploy network. After all, you're trying to avoid dependencies on things like Github working/failing, right? ;-)
rds2000 13y ago
Package library systems like this are mirrored on CDN's and often cached locally in the user's `$HOME` folder in some way (at least in the case of npm and bower). If someone's downloading your repo, why wouldn't they mind getting their dependencies the normal way? Also, there is the benefit of your git history not having to track vendor libs, and you being able to lock versions in. This is about convenience to yourself as a developer, as well as others. Feel no need to include vendor libraries :), it's ok.
jarofgreen 13y ago
I do this. I know what you are meant to do is check in your composer.json and composer.lock then do a composer install on the server. But then you have a external dependency on your install process on live servers, which is a terrible idea. To got around this, I've seen companies say "we have our own package mirror". Or you could just check in the vendor folder? Another reason I do it: My software package is used by people who aren't PHP programmers and I want them to be able to just grab the files and go with no fuss. I do appreciate having the vendor folder in git takes space and is a pain ... but I think the trade off is worth it.

by elwell 13y ago

SEJeff 13y ago

If you must... use submodules.

meritt 13y ago

That's what composer is for

markdown 13y ago
what is composer, and why do I have to learn it if it is completely unnecessary?
- sexmonad 13y ago
  What is <insert technology>, and why do I have to learn it if <insert worse technology> is sufficient?
- ianhawes 13y ago
  Composer is the de facto PHP package manager, and it is highly recommended for modern PHP applications.

Tomdarkness 13y ago

There is a composer.json and composer.lock file in the repository. All you'd need to do to download all the dependencies is have composer installed and run "composer install".

MichaelGG 13y ago
Thus making your application build process require full Internet connectivity, and making it require that every dependency hosting site is working. Committing dependencies is a solid decision to avoid taking a dependency on a bunch of third parties.
- lstamour 13y ago
  "application build process" or simply the checkout process? I'd suggest your deployment process shouldn't include a public git repo others can change. Instead, use your own fork on Github, or alternatively host a git repo local to your deploy network. After all, you're trying to avoid dependencies on things like Github working/failing, right? ;-)

rds2000 13y ago

Package library systems like this are mirrored on CDN's and often cached locally in the user's `$HOME` folder in some way (at least in the case of npm and bower). If someone's downloading your repo, why wouldn't they mind getting their dependencies the normal way? Also, there is the benefit of your git history not having to track vendor libs, and you being able to lock versions in. This is about convenience to yourself as a developer, as well as others. Feel no need to include vendor libraries :), it's ok.

jarofgreen 13y ago

I do this. I know what you are meant to do is check in your composer.json and composer.lock then do a composer install on the server. But then you have a external dependency on your install process on live servers, which is a terrible idea. To got around this, I've seen companies say "we have our own package mirror". Or you could just check in the vendor folder? Another reason I do it: My software package is used by people who aren't PHP programmers and I want them to be able to just grab the files and go with no fuss. I do appreciate having the vendor folder in git takes space and is a pain ... but I think the trade off is worth it.