"and even a git status takes 30 seconds to run"
That's a problem with your vcs, not with the (defensive) practice of tracking external dependencies.
While sensible advice, usually only the VCS approach works across many organizations, which don't provide the resources to do it in any other more reasonable way.
Checking your dependencies in is a good idea. When you check out a version from some time ago, you won't have to worry if those versions are still available in your cache or on remotes. Especially if the package manager is not very dependable. Furthermore, if you patch or edit your dependencies, that information is permanently recorded too.
At my job we almost never version control our vendor directory, but you have a very strong point, and I am not strongly in our camp. One pain point in particular, is that if you are using Git Bisect to find out where a bug appeared, and you don't have your dependencies version controlled, you either have to run "composer install" at each bisect step, or set up an equivalent checkout hook. And while I guess the checkout hook could work, it is going to make a lot of other work a lot slower.
Re:What, why and how of PHP Composer
by workinthehead on Thursday June 14, 2018 @04:53PM
(#17315273)
If `git status` is literally taking 30 seconds to run, it's not because you checked in your vendor dir lol.
Seriously, version control systems are specifically built to handle that kind of thing. You're mistaken as to the cause of your perceived slowdown.
Never say never, either. You don't know my life.
You should never VCS the vendor directory. If you are concerned about disappearing 3rd party dependencies, you should:
- have a local cache - keep e.g. git mirrors for 3rd party dependencies - invest a bit more time in selecting dependencies with higher quality.
I've seen repos with vendors checked in. A few years, hundreds of thousands of commits, and even a git status takes 30 seconds to run.
Just saying, there is a more sensible approach that beats storing vendors in the project :-)