Major and minor versions usually are sufficient, as you can lock to a specific version anyway.

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 :-)

"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.

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.

Instead of including the vendor folder into projects you may use satis [0] to "mirror" all of your dependencies. That means you will not have any broken stuff if packagist is down or any of your dependencies are missing.

[0]: https://github.com/composer/satis

IMO for the first point you should rather use ^x.y with the minimum version you require and then accept new releases as they come. If you do regular updates you should notice quickly when something break and be able to revert that update easily. If you update 20 packages at once it becomes harder to pinpoint where a regression occurred.

As for including the vendor dir in your VCS repo, this comes with quite a few drawbacks. That's one of the things Private Packagist (https://packagist.com) aims to fix though, as it keeps mirrored copies of your dependencies' zip archives so you get more reliable installs.

What guarantees you that packagist will be around in e.g. 15 years when you would like to start some old project?

If you are talking about such long time frames, then indeed archiving a project with its vendor directory might be a good idea once you decide to relegate it to the freezer.

How about "vendor decided to migrate off Github last week, and managed to break all their tags in the process"? (Not that this would have actually happened to me this Monday, noooo ;)) Long timeframes are not the only issue with external dependencies...

You don't need (and shouldn't depend on) packagist when using Composer. You can import packages directly from Github, Bitbucket, etc., or even locally, you just have to write a bit more JSON.

What do you suggest when the package you are using is pulling in other packages from packagist?

Rewrite your composer.json to include them directly?. The lock file probably contains the actual repository URLS so once you have a dependency tree resolved you can rewrite it based on that.

But it is possible to avoid packagist. Ugly and painful maybe but possible, and YMMV regarding the effort being worth the reward. Dependency management in PHP isn't (or shouldn't be) like it is with JS/Node where there is one authoritative registry that everyone has to depend on and that can assert direct influence over the community as a result. Packagist shouldn't be the PHP package registry, but a registry.

The fact that I need packagist, and the basic structure is really easy to copy? If not packagist, then someone will have set up a package repository with a different name.

> * Use full version numbers for your dependencies.

The tradeoff for this approach is to have to resolve version conflicts manually anytime there is more than minor dependency changes.

In particular, adding a package that is newer than most of your dependencies can be a nightmare when you locked down all the working revisions of your libraries.

On one hand there is less drama about packages changing under one's feet, on the other hand part of composer's job is shifted back to the dev who does the package updates.

Personally I would advise a more balanced approach of allowing minor version changes and only block major ones.

You always choose a reliable dependency not something random. I never had similar experience or saw a project doing that.

You should only version composer.lock and composer.json files. Ignore vendor directory and leave that job to your build step in CI/CD...

That's why we have our own composer repository powered by satis. When set up correctly, it can be used as a "proxy" for packagist, ensuring you always have an installable version of your dependencies, even if they are not available via packagist anymore.

Most insightful comment on this thread. I'm looking into satis now, thank you!

https://github.com/composer/satis

Things disappear, or get deleted, or old versions get replaced for various reasons. There's no "reliable dependency". Even if you think something's reliable, sone deeper dependency may disappear. See npm and left-pad for example.

Committing vendor directory may or may not be a good idea. But having your own copy of all dependencies (current and past) is necessary.

> But having your own copy of all dependencies (current and past) is necessary.

Definitely! Git mirrors are cheap, and there are various solutions for composer proxies out there. If you consider CI/CD you will want freedom from external calls anyway.

Your build system should take care of this for you. For example, build a docker image or store an artifact (e.g. zip file) of the full build including dependencies. Then put it on your own docker registry or the artifact on S3, for example.