Composer - the right way

We have had a very interesting and heated discussion with colleagues about the use of Composer in the projects we are working on. I would very much like to hear the “general public” opinion on this issue.

The stumbling block was a very simple question:

Should I keep the contents of the vendor folder in our repositories?

As you, in general, probably already guessed, opinions are divided:

YES

This is part of our application, for which we are responsible and all dependencies should be stored in one place. In this case, it is meant that without third-party libraries, our code loses its functionality.

Counter-argument : in this case, we also need to get used operating system level packages into our repository (apt-get, for example). After all, when using a similar tool in Java - Maven, for example, no one stores third-party dependencies, but only a description of them. This also includes npm, pip and others.
')
NOT

These are 3-rd party libraries that we simply use. The desired effect of "immutability" can be achieved by hard fixing the version of the library in composer.json.

Counter-argument : lack of control over the development of third-party code. In case of closure or “bad code” in the vendor project, we lose functionality.

To complete the picture, please pass a short survey.

References:

• Composer - getcomposer.org
• Apache Maven - en.wikipedia.org/wiki/Apache_Maven

UPDATE 1
As dependencies in this case we mean the official SDK for third-party APIs , for example, or automation tools . Those. These packages can not disappear in 1 day.

UPDATE 2
Discussion means storing the vendor code neither on the packagist proxy, nor in separate forks, but directly in the repository with the project .

UPDATE 3
A project means a certain web application or service, but not a library developed by a company.

UPDATE 4
The project has been actively using build to build js / css files. This is important because the assembly of php dependencies should be included in this process (according to the author).

UPDATE 5
The aforementioned builds are launched on a test environment (or a special build server) and roll out to the combat servers already in finished form. This means that the situation with different versions of packages between test / stage / live is not possible in principle.

UPDATE 6 & FINAL
Thank you all very much for the discussion, links and opinions. The effect of the article turned out exactly as the author intended.