Don’t commit the composer.lock file if you are working on a library or package that is intended to be used only as a dependency for other projects, usually in very different projects. Furthermore, you should ensure that you list properly the package versions that your project depends on, in order to avoid conflicts in the projects where it will be installed and to maximize its compatibility. This is why you shouldn’t use the composer require command to install the dependencies, or, in case you do it, you should review manually the version added to the composer.json and ensure that it covers all the versions that are compatible with your project.
for deploying laravel in the latest laravel podcast they were kind of talking about composer.lock in forge or even committing your vendors packages in some cases because composer can take so long to compare and figure out the right versions and the worker processes on forge top out at 8 minutes.
while we are on this issue (and sorry to hijack this thread).. i have a little confusion.. currently i always do composer update, which updates my packages & updates lock..
so the 'right process' would be to
put the lock file with the git
when you go to server instead of doing composer update, you do composer install?
the problem i have encountered is sometimes I add in a new package in json file and when i do composer install nothing happens until I do composer update which at that point also updates other packages? Or should i use the other command composer require 'package name' ?
@shez1983 yup. You only run composer update when you want to actually update to newer versions of installed packages. Use composer require to add new packages, or require-dev if it's a dev only package..