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

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.

"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? ;-)

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.

That's what composer is for

what is composer, and why do I have to learn it if it is completely unnecessary?

Composer is the de facto PHP package manager, and it is highly recommended for modern PHP applications.

What is <insert technology>, and why do I have to learn it if <insert worse technology> is sufficient?

If you must... use submodules.