<p>I guess you are running <code>composer update</code> to update craft. A composer update usually updates your <em>composer.lock</em> and the <em>vendor</em> folder. The composer.json defines your dependencies (and some additional information) and should never be changed by a composer update.</p>

<p>If you have the possibility I would use <code>rsync</code> with some excludes (for example the user upload folder(s)) to deploy your complete project, makes things easier.</p>

CC BY-SA 4.0
2019-05-22T14:37:33.183Z
2019-05-22T14:37:33.183Z
Phillip
<p><code>composer.json</code> and <code>composer.lock</code> aren't <em>technically</em> the only files that change; for example some of the files in the <code>vendor</code> folder change each time you update. If you're using Project Config, occasionally the <code>project.yaml</code> file will change if a plugin update makes some data architecture changes or something.</p>

<h3>Some Info on Composer and Craft and Updating</h3>

<p>The only time <code>composer.json</code> would change on an update is if you ran the update via Craft's updater. When you use Craft's updater, it disregards what is specified in the <code>composer.json</code>; it does its own checking and when it updates a package it locks the packages down in the <code>composer.json</code> to that particular version number. However, when you use <code>composer update</code> to do your updating, it will use what is specified in the <code>composer.json</code> to do see if there are any new versions that match the specified <a href="https://madewithlove.be/tilde-and-caret-constraints/" rel="noreferrer">semantic versioning constraints (semver)</a>; running a <code>composer update</code> changes nothing in your <code>composer.json</code> file.</p>

<p>Here's an example of what the difference might look like:</p>

<pre><code>1) "nystudio107/craft-seomatic": "3.2.3",   // Craft updates style (note the absolute version number)

2) "nystudio107/craft-seomatic": "^3.1.0",  // Composer semver style (note the '^')
</code></pre>

<p>When you run Craft's updater; it won't matter which of these lines you use. Craft will do its own checking and overwrite the current semver as necessary. If you use <code>composer update</code>, #1 won't allow you to install anything other 3.2.3 because that is what is explicitly declared; #2 will allow anything that fits 3.X.X. So if you've used Craft's updater in the past, you'll need to manually add <code>^</code> or <code>~</code> to your version numbers before <code>composer update</code> has any affect.</p>

<p>The <code>composer.lock</code> file works quite similarly to the way the Craft updater uses the <code>composer.json</code> package version numbers. It's basically a big file that contains the installed version number (as well as a bunch of other stuff) of every single package as well as all the dependencies. It changes any time you update, whether via Craft or composer.</p>

<p>Then you've also got <code>composer install</code> which behaves differently than <code>composer update</code>. <code>composer update</code> takes the semver provided in the <code>composer.json</code> file and checks to see if any newer version that fits the constraints are available, if so it installs it. <code>composer install</code> looks in the <code>composer.lock</code> file and installs whatever is specified there. This means that running <code>composer install</code> on an existing codebase should have no effect provided everything's previously been installed.</p>

<h3>A Typical Craft Upgrade Strategy</h3>

<p>Here are the typical steps for updating your Craft sites locally and pushing those changes to a live/production server.</p>

<ol>
<li>Depending on whether you use Craft or composer for your updating:

<ul>
<li>Run <code>composer update</code> locally. Again, this fetches any newer package versions that comply with the semver, installs them, and makes the necessary changes to the <code>composer.lock</code> file. <strong>OR</strong></li>
<li>Run Craft's updater locally. Again, this fetches any newer package versions, installs them, and makes the necessary changes to the <code>composer.json</code> and <code>composer.lock</code> file.</li>
</ul></li>
<li>Depending on the nature of the updates, you may need to run a database migration locally. You'll also want to quickly test your site and make sure nothing broke because of the updates.</li>
<li>You'll commit the changes to <code>composer.lock</code> (and if you used the Craft updater, the changes to <code>composer.json</code>) and merge branches / push to your remote Git repo per your typical process.</li>
<li>Usually you'll have some sort of deployment process setup (<a href="https://buddy.works/" rel="noreferrer">Buddy</a>, <a href="https://deploybot.com/" rel="noreferrer">DeployBot</a>, <a href="https://forge.laravel.com/" rel="noreferrer">Laravel Forge</a> deployments, etc) that watches your remote Git repo and does a deployment every time you push. This deployment usually looks like a <code>git pull</code> of the latest changes and then, depending on your deployment tool of choice, this next step might be done on the deployment server and the resulting files pushed to the live server or it might be done on the live server itself...</li>
<li><p>You'll typically need to do several things as part of the final step of the deployment process:</p>

<ol>
<li>Run <code>composer install</code> - remember, this takes that <code>composer.lock</code> file (which is now different from the files in the vendor folder on the live server) and installs anything it can (i.e. if the lockfile and the vendor folder agree on a certain package, it skips it; otherwise it updates it).</li>
<li>Run your database migration on the live site.</li>
<li>If you're using project config, and the project config file changed during the updates, you'll want to sync any changes there.</li>
<li>Finally you'll want to clear caches so you get the latest and greatest on the frontend of your site.  </li>
</ol>

<p>These steps take some time to do manually, which is why it is a good idea to automate them. You can run them all via the CLI via your deployment tool, but an even better idea would be to add them to the <code>scripts</code> in your <code>composer.json</code> file. For example:</p>

<pre><code>...
"scripts": {
  "post-install-cmd": [
    "@php craft migrate/all",
    "@php craft project-config/sync",
    "@php craft clear-caches/all"
  ],
  ...
},
...
</code></pre>

<p>If you add that to your <code>composer.json</code>, any time you run <code>composer install</code> those other three commands will be run directly after.</p></li>
</ol>

<hr>

<p>My apologies on the short answer, I was pressed for time. JK lol </p>

CC BY-SA 4.0
2019-05-24T12:25:30.717Z
2019-05-24T12:25:30.717Z
Jalen Davenport
<p>This is a newbie question regarding running Craft updates. In the past I've been caught out by stupidly running updates on the live server. I'm now trying to get into the habit of running the updates on a local version, then pushing that to the live version - the proper way of course. Am I right to assume that the only files that have been changed after an update are composer.json and composer.lock (along with the db)?</p>

<craft3><updating>
Running Craft updates
# Running Craft updates

(Asked by: username_0 on 2019-05-22)

This is a newbie question regarding running Craft updates. In the past I've been caught out by stupidly running updates on the live server. I'm now trying to get into the habit of running the updates on a local version, then pushing that to the live version - the proper way of course. Am I right to assume that the only files that have been changed after an update are composer.json and composer.lock (along with the db)?

**Tags:** craft3, updating

---

## 2 answers

### Answer by username_1 on 2019-05-22. Score: 1 | Accepted answer

I guess you are running `composer update` to update craft. A composer update usually updates your *composer.lock* and the *vendor* folder. The composer.json defines your dependencies (and some additional information) and should never be changed by a composer update.

If you have the possibility I would use `rsync` with some excludes (for example the user upload folder(s)) to deploy your complete project, makes things easier.


---

### Answer by username_2 on 2019-05-24. Score: 9

composer.json and composer.lock aren't technically the only files that change; for example some of the files in the vendor folder change each time you update. If you're using Project Config, occasionally the project.yaml file will change if a plugin update makes some data architecture changes or something.
Some Info on Composer and Craft and Updating
The only time composer.json would change on an update is if you ran the update via Craft's updater. When you use Craft's updater, it disregards what is specified in the composer.json; it does its own checking and when it updates a package it locks the packages down in the composer.json to that particular version number. However, when you use composer update to do your updating, it will use what is specified in the composer.json to do see if there are any new versions that match the specified semantic versioning constraints (semver); running a composer update changes nothing in your composer.json file.
Here's an example of what the difference might look like:
1) "nystudio107/craft-seomatic": "3.2.3",   // Craft updates style (note the absolute version number)

2) "nystudio107/craft-seomatic": "^3.1.0",  // Composer semver style (note the '^')

When you run Craft's updater; it won't matter which of these lines you use. Craft will do its own checking and overwrite the current semver as necessary. If you use composer update, #1 won't allow you to install anything other 3.2.3 because that is what is explicitly declared; #2 will allow anything that fits 3.X.X. So if you've used Craft's updater in the past, you'll need to manually add ^ or ~ to your version numbers before composer update has any affect.
The composer.lock file works quite similarly to the way the Craft updater uses the composer.json package version numbers. It's basically a big file that contains the installed version number (as well as a bunch of other stuff) of every single package as well as all the dependencies. It changes any time you update, whether via Craft or composer.
Then you've also got composer install which behaves differently than composer update. composer update takes the semver provided in the composer.json file and checks to see if any newer version that fits the constraints are available, if so it installs it. composer install looks in the composer.lock file and installs whatever is specified there. This means that running composer install on an existing codebase should have no effect provided everything's previously been installed.
A Typical Craft Upgrade Strategy
Here are the typical steps for updating your Craft sites locally and pushing those changes to a live/production server.

Depending on whether you use Craft or composer for your updating:


Run composer update locally. Again, this fetches any newer package versions that comply with the semver, installs them, and makes the necessary changes to the composer.lock file. OR
Run Craft's updater locally. Again, this fetches any newer package versions, installs them, and makes the necessary changes to the composer.json and composer.lock file.

Depending on the nature of the updates, you may need to run a database migration locally. You'll also want to quickly test your site and make sure nothing broke because of the updates.
You'll commit the changes to composer.lock (and if you used the Craft updater, the changes to composer.json) and merge branches / push to your remote Git repo per your typical process.
Usually you'll have some sort of deployment process setup (Buddy, DeployBot, Laravel Forge deployments, etc) that watches your remote Git repo and does a deployment every time you push. This deployment usually looks like a git pull of the latest changes and then, depending on your deployment tool of choice, this next step might be done on the deployment server and the resulting files pushed to the live server or it might be done on the live server itself...
You'll typically need to do several things as part of the final step of the deployment process:

Run composer install - remember, this takes that composer.lock file (which is now different from the files in the vendor folder on the live server) and installs anything it can (i.e. if the lockfile and the vendor folder agree on a certain package, it skips it; otherwise it updates it).
Run your database migration on the live site.
If you're using project config, and the project config file changed during the updates, you'll want to sync any changes there.
Finally you'll want to clear caches so you get the latest and greatest on the frontend of your site.  

These steps take some time to do manually, which is why it is a good idea to automate them. You can run them all via the CLI via your deployment tool, but an even better idea would be to add them to the scripts in your composer.json file. For example:
...
"scripts": {
  "post-install-cmd": [
    "@php craft migrate/all",
    "@php craft project-config/sync",
    "@php craft clear-caches/all"
  ],
  ...
},
...

If you add that to your composer.json, any time you run composer install those other three commands will be run directly after.


My apologies on the short answer, I was pressed for time. JK lol


---

