Issue
I recently started a project using composer for the first time, and I just deployed it to Q&A (demo), with git I used to just do a git pull
and update the Q&A environment, but now with composer update
only the dependencies get updated.
My question is, what is the SOP(standard operating procedure) for updating the core project, do I still use git, or is there a way to do it with composer?
Or am I completely doing this wrong, and should be working out of the vendors folder?
Solution
The point of Composer is that you don't need to version control the dependencies which means anything that ends up in vendor/
.
The project has a composer.json
and composer.lock
. These are within git's control so it knows the packages and versions to use. However, the vendor/
directory should be ignored, with .gitignore
. If you don't already have that set up simply add this line:
/vendor/*
You version control your other files as normal.
So the operating procedure is to use git and normal. Followed by composer update
.
The advantage of this setup is that git doesn't have to bother managing potentially thousands of files (inside vendor/
) that will never normally change. The only circumstance under which they'd change is if you want to start using a different version of a package, or adding new ones. Well, all of those packages/versions are defined in your composer.json
(which git is monitoring for changes). All you need to do is run composer update
and it will update everything in your vendor/
directory to the "right" version.
That's one of the advantages of using Composer - all developers can have a "list" of the correct packages/versions, without the need to version control all of the files in them.
Edit as per the comments below:
Note composer update
should only be run in development. Use composer install
when deploying to QA or production. This will install the exact versions referenced by your composer.lock
file.
Answered By - Andy
0 Comments:
Post a Comment
Note: Only a member of this blog may post a comment.