Why don't you put the vendor directory under Git management?

Benefits of inclusion in repository

• No need to install Composer in each environment
• All you have to do is git pull even if there is a change in the dependent package
• In some cases, clone/pull per repository is faster than composer install yourself

Disadvantages

• Increase repository size and compress disk.
  (Removing or modifying dependency packages will continue to remain with past commits)
• In the framework, the number of files increases by thousands, which can slow down the normal Git operation (mainly Windows).
• Changing dependent packages results in a large amount of diff.If you want to use tools like Github or Bitbucket to view history, or if you want to check the merge, it may be a hindrance.
• For Windows and Linux, the files generated in vendor/bin are slightly different.
• If by any chance you forget to commit package.jsonpackage.lock or vendor/, it will lead to "It works on hand..."This is not limited to vendor commitments, but more files may make it harder to forget to commit.

The disadvantages listed above may be trivial depending on the environment, operation method, and preference, but I don't think the advantages are that great.If this is not a PHP tool, I think it would be better to build an environment, but if you have a PHP development and execution environment, you just have to leave composer.phar and run it...

If it's not a deployment using Git, I think it's common to consolidate composer install into zip and distribute it.

Do you run composer update in the production environment?

You should use composer install instead of composer update.

Roughly speaking, the former finds and installs the latest version of the dependent package on the spot, while the latter installs the version recorded in composer.lock.This ensures that you install a version that exactly matches your development environment.

Also, composer install takes less time to search for packages and resolve dependencies