Is it possible to keep vendor folder in git after composer update?

Question

PHP

When using the composer package manager, all the packages necessary for the project are stored in the vendor folder, while the generally accepted practice is that this folder cannot be added to git, instead, each developer after git clone must do composer install and periodically composer update.
I don't like this approach for the following reasons:

1. If one developer updated the libraries, others should somehow find out about it in order to update themselves
   
2. The list of libraries and versions are not updated very often, and with each release, you have to download the same libs
   
3. The project can be occupied by people who do not know how (or cannot currently) work with the console: layout designers, technical writers, a code (security) reviewer, here is the question of paying a specialist who can do everything
   
4. There is no way to easily and quickly transfer code to someone by simply sharing a link to git
   

The question is, is it possible to save the vendor folder in git, how much does it contradict the accepted style and what problems can there be with this (now I see the fattest minus from this approach in the swelling of the repository)? Does anyone use this practice in their projects?

Answer 1

> others should somehow find out about it in order to update themselves
well, you use the git, right? do you use it right?
git fetch origin
git diff --name-only <yourbranch>..origin/<yourbranch> -- composer.json or whatever

Answer 2

If one developer updated the libraries, others should somehow find out about it in order to update themselves

If other developers do a git pull and don't pay attention to the changes, that's their problem. It's good practice to notify the author of changes to composer.json that others should update it.
Generally speaking, the composer knows how to cache and the same versions of the libs are pulled from the cache.
If you just need to raise the environment with the project, set up vagrant and write in the README how to use it specifically for your project.
As for people:
* layout designers - vagrant
* technical writers - of course, I'm not aware of your project, but I wouldn't even give access to the repository, at most - I started a separate repository for them.
* code reviewer (security) - reviewer that can't in composer/console?? The joke is not good.
* here is the question of paying a specialist - lolshto? It has nothing to do with the environment of your project at all, not a bit.
If your project is NOT opensource, then in principle this cannot be done. Access to the repository should be provided to specialists who work with the code of this project and no one else, but composer has nothing to do with it!
NO! You came up with a non-existent problem and are trying to heroically solve it, only this solution will make it even worse.
to the full
1. You become a vendor of the code that you took somewhere, as a result, you follow its updates from the original vendor and you make similar edits in your project. If you do not do this, the bugs found in this dependency will not fix themselves and this code will quickly become obsolete.
2. The temptation to carry out your own developments appears in the dependency code - this is something that cannot be done, otherwise the update process will be orders of magnitude more difficult.
3. Your repository will swell.
4. The composer will have to explicitly register your dependency, otherwise the autoload may not pull it up.
A couple of years ago I worked on a large project that started before the advent of composer. When there are a lot of dependencies and you don’t know which of them contain artifacts of your own developments, which ones are updated synchronously with official vendors, and which ones are pulled from outside, you have to spend a lot of time figuring out. This is a fucked up time.

Answer 3

It's possible, but it doesn't make sense.
Instead, we put composer.lock in the git and hung a git hook that does composer install during merge and checkout.
After that the problem went away.