Yarn: `yarn upgrade-interactive` does not update package.json

[alexdevero]

What is the current behavior?
After updating to Yarn v1.0.1 yarn upgrade-interactive does not update package.json. In Yarn v0.28.4, running yarn upgrade-interactive and updating dependencies always also updated dependency versions package.json.

If the current behavior is a bug, please provide the steps to reproduce.

Run yarn upgrade-interactive in project with outdated dependencies and update at least one page. After update, only yarn.lock is updated.

What is the expected behavior?
Running yarn upgrade-interactive should update dependency version in package.json as it did in version v0.28.4.

Please mention your node.js, yarn and operating system version.
Node: v8.4.0
Yarn: 1.0.1
Windows 10 (1703)

[dean992008]

I also have the same problem.
Node: v6.11.3
Yarn: 1.0.1
Linux Mind.

[blobor]

Same with:
Node: v8.4.0
Yarn: 1.0.1
MacOS

[kaylie-alexa]

With 1.0.0 release, upgrade-interactive will respect package.json by default and will require --latest flag to be passed to replace the versions. Here is the rfc and the docs. Closing this for now.

[alexdevero]

@kaylieEB thank you for explanation.

[f]

Assume we have a package.json with old versions of some packages. This is what I do:

rm -rf node_modules yarn.lock
yarn install

This installs the packages (package.json is not updated)

yarn upgrade-interactive --latest

This says everything is up to date, but my package.json is still same.

Thanks.

[BYK]

@f - your scenario sounds a bit different than the initial report. Would you mind sharing your package.json in a new issue so we can try reproducing this?

[henry74]

This appears to update package.json and upgrade all yarn outdated packages to the latest version:

yarn upgrade --latest

[SenHeng]

Having played around with the commands a bit, I think what happens is that when all dependencies have been updated, --latest will do nothing.

Solution is to simply undo (git reset or delete) your yarn.lock file, then upgrade it again.

[alexdevero]

@SenHeng using --latest flag will upgrade all dependecies/devDependecies to their latest versions AND update both, yarn.lock and package.json.

[SenHeng]

@alexdevero

As I said in my previous message, using the --latest when my dependencies were already updated would not upgrade the package.json. The only way was to either delete or undo any changes made to yarn.lock, and then run yarn upgrade --latest.

Series of events that I did.

$ yarn upgrade
// upgrades everything, whoops, package.json not updated
$ yarn upgrade --latest
// does nothing
$ git reset --hard
// undo changes to yarn.lock
$ yarn upgrade --latest
// this time, package.json gets updated.

[alexdevero]

@SenHeng It is expected that after you run yarn upgrade and upgraded packages, yarn upgrade --latest command will do nothing -> there is nothing to update for yarn and hence no reason to modify package.json. When you undo the changes to the yarn.lock, it will find updates and, in that case, it will have a reason to modify itself and package.json if you now run yarn upgrade --latest.

After reading you comment again, I have to wonder, what did you expect after running yarn upgrade and then yarn upgrade --latest?

[SenHeng]

@alexdevero I thought it would update the package.json to the latest versions

[alexdevero]

@SenHeng It doesn't make any sense. If packages in node_modules are up to date, there is no reason for yarn to do anything if you use command for update.

[bartvanandel]

I agree that the current behaviour is a bit weird. Suppose you have a package.json like this (mock code):

{
  "dependencies": {
    "pkg-a": "^1.0.0",
    "pkg-b": "^2.0.0"
  }

The real installed versions are 1.1.0 and 2.0.0 respectively, while the latest versions are 1.1.0 and 2.1.0. Now running yarn upgrade --latest will install [email protected] and update package.json accordingly, but pkg-a will not be updated and hence, package.json will still point to 1.0.0. This has bothered me for some time as well because package.json is arguably more human readable than yarn.lock, so this is where we usually inspect what is expected to be installed (plus, some coworkers are still using npm or forget to push changes to yarn.lock, leading to even more inconsistencies).

As far as I'm aware there isn't a command currently to instruct yarn to sync package.json to the actual versions. If we had an actual yarn sync command for this I'd be quite happy.

[alexdevero]

@bartvanandel I like the idea you proposed about command for syncing yarn.lock and package.json files.

[scharf]

Here is another problem with not updating package.json when yarn.lock changes: There are quite a few bugs where the suggestion is: delete yarn.lock:

• #1625
• #2738
• and probably many more

After deleting yarn.lock all you have is a totally outdated package.json which may not reflect the versions you are using in the yarn.lock. During the interactive update, you may have chosen not to update some specific packages -- all those decisions are not reflected in the package.json. It would be great to have a way to keep the two in sync.

[emulvihill]

This issue needs to be addressed. It is, and always will be, important to know EXACTLY what versions you are using. Semver is a wonderful theory but the real world is always a bit different than theory. Please make it easy & less confusing for us to keep package.json updated! Thanks.

[BYK]

Please make it easy & less confusing for us to keep package.json updated! Thanks.

Feel free to contribute to make things easier and less confusing both for yourself and the whole community? 😉

[danieledler]

Using the --latest flag to update package.json is semantically confusing, and doesn't work if you want to upgrade alpha/beta versions. For example, I use the vuetify package, with this result from yarn outdated:
Current: 1.0.0-alpha.3
Wanted: 1.0.0-beta.1
Latest: 0.17.6

Running yarn upgrade[-interactive] --latest just to update package.json would _downgrade_ my current version, which is no option.

Running yarn upgrade[-interactive] would upgrade to the Wanted version and update yarn.lock to reflect that upgrade, but package.json would _not_ be updated. I then have to manually update package.json to let git teammates upgrade accordingly, which reduces the value of this tool completely for me. I would definitely expect yarn to update that.

[elimcjah]

We are running into the same problem. We've tried

$ yarn upgrade

$ yarn upgrade --latest

$ yarn upgrade-interactive

$ yarn upgrade-interactive --latest

The updated version appears in the resolved section of the yarn.lock file.
The package.json does not reflect the correct version number for each of the upgrades.

Is there any other way to have resolved version number from the yarn.lock write to the package.json?

[elimcjah]

Our solution was to verify that the carot(^) in the package.json file was only in front of version numbers. It was so we did a find replace and just removed all (^)s from version numbers. Removing the carot(^) from in front of the version number in the package.json then running

$ yarn upgrade --latest

upgraded all the version numbers in the package.json to match the resolve of those packages in the yarn.lock file.

Next, we went back and just added the carot to all the version numbers again in the package.json.

It was a fast easy solution. Instead of trying to find a work around anywhere else.

[luisrudge]

I also agree that not updating the package.json file is super counter intuitive.

[bartvanandel]

@Noiwex We know they should both be versioned. We know what the purpose of package.json and yarn.lock is. The former is human readable and easy to understand, the latter is a mess to any human. Syncing the actual versions installed by yarn into package.json on demand is what we want. That's not currently possible with a useful command. And that's exactly what I, and other devs with me, would very much like to have. So yes, it is an issue.

[lostpebble]

The main problem I see with this is that my package.json versions are never changed, but the actual lock file versions are now changed - which essentially means that for those versions I have in package.json they are now installing new versions behind the scenes. And will always do so going forward now because of yarn.lock.

What if these new versions actually break my code?

If I've done a bunch of work and I only realise later that a single dependency is breaking things. There is no easy way for me to revert back to the previous versions - because my package.json dependencies are pointing to the new bad versions behind the scenes. The only way would be to do a hard version dependency in the package.json without the ^, but that's not ideal - because the one that worked might not have been that exact version (as per the previous yarn.lock file) and this also makes this dependency rather stagnant in nature.

I just wish there was an argument we could pass to upgrade-interactive that makes it edit the package.json file as well to the versions we upgrade to - this way if we revert to the previous version in package.json, yarn.lock should still remember the exact version we intend.

--latest is not a solution. Because we don't always want to upgrade to the latest version.

[hanxue]

@BYK I think it is worth having an option for yarn upgrade to also update the package.json file. In my case, I upgraded to webpack 4 when it was in alpha/beta, and now when I upgrade to the latest stable version of webpack, I don't want to leave "webpack": "^4.0.0-beta.2" in package.json

I have also seen a number of issues regarding the confusion of package.json not being updated when running yarn upgrade. Perhaps a --update-package-json flag?

[ZakTax]

Ran into same issue today. I agree that there needs to be a way to keep package.json in sync.

[StefanoVollono]

same issue for me today

[rafaelrinaldi]

Having issues with this for a while as well. If the maintainers are interested I can attempt a PR.

[marcofugaro]

yarn upgrade-interactive --latest now has this behaviour also

[murbanowicz]

I am facing this issue right now.
yarn upgrade-interactive --latest
yarn upgrade --latest
Both do not update package.json even if all packages in node_modules gets updated.

I am working with workspaces project.

[grigio]

I confirm this bug should be opened again yarn upgrade --latest do not upgrade package.json

[lostpebble]

This whole thing defeats the point of a lock file. Its very frustrating because all that these upgrade commands do is modify the lock file but not the actual package.json! It makes no sense. It should modify them both, and set a new record in the yarn.lock file referencing the new version in the package.json for this upgrade iteration.

As I mentioned before (almost a year ago now... seems like nothing is being heard though), the way it acts now is actually very dangerous to your code base because if down the line you decide you actually need to go back to that previous version of a dependency - your lock file has now changed what your old version actually is locked to.

I've dealt with this before - it was a very tedious fix and not at all obvious what was wrong at first - and its the reason I actually _never_ use these features anymore. I manually update everything, and it sucks.

The last time this happened I had to go searching through old git commits to find the state of the lock file at that time.

I honestly can't think of any reason why it was built in the way it is now. And its such a simple fix - Just update both the package.json and the yarn.lock files together - keeping the old lock file dependency links in tact.

[grigio]

@lostpebble Yes or at least a yarn upgrade --save option

[tuurbo]

I use yarn upgrade-interactive --latest which updates both the package and lock file

[grigio]

@tuurbo Nope, It worked in a past project but in the current one not. I also tried to remove yarn.lock

[lostpebble]

I use yarn upgrade-interactive --latest which updates both the package and lock file

The reason for this is because the major version is changing - so yarn is forcing itself to update the package.json as well - as semantically it can't work any other way (yarn can't link 7.0.0 in package.json to 8.0.0 in the lock file - at least there its functioning correctly in this). All I'm saying is that these version numbers in package.json should change always, even on minor and patch version updates.

So using --latest is not a solution- and besides the fact that it doesn't touch minor or patch updates, as I also mentioned earlier: we don't always want to upgrade to the latest version. So its pretty much irrelevant to this issue.

@tuurbo Nope, It worked in a past project but in the current one not. I also tried to remove yarn.lock

@grigio I assume that the updates you are doing, even with the --latest flag, are either minor or patch updates? That might be why yarn is falling back to its regular (incorrect) behaviour of doing nothing to the package.json.

[Risto-Stevcev]

To add to what @lostpebble said, you can also end up with a lockfile that contains multiple versions of the same library by accident if you aren't flatting the tree:

$ yarn upgrade-interactive
# User notices that package.json wasn't updated, comes to this thread and then tries to fix it
$ git checkout -- yarn.lock  # remove the lockfile changes
$ yarn upgrade-interactive --latest  # using the current workaround
# User notices that there are multiple versions now appearing in the lockfile

Granted this won't happen if you flatten the tree with yarn upgrade-interactive --flat --latest, but some teams don't have or can't have a flattened tree.

[fvonellerts]

@lostpebble That's exactly my problem, this is a serious flaw in yarn!
The only solution I found is to use yarn upgrade --latest [email protected] which is terribly unintuitive.

[bartvanandel]

Honestly, given the response from the yarn devs, I wouldn't hold my breath about any PRs for this subject being accepted. I do have a script for this very purpose on my local machine (with some limitations), if anyone's interested I can post it in the coming days.

[rublev]

I do have a script for this very purpose on my local machine (with some limitations), if anyone's interested I can post it in the coming days.

would be greatly appreciated 👍

[bartvanandel]

Apparently I already uploaded a script a while ago, in javascript. Wasn't aware of this and re-created it in Python. Well why not upload both then :)

Here you go: https://gist.github.com/bartvanandel/0418571bad30a3199afdaa1d5e3dbe25

The main limitation is that it only supports simple version semver-like specs, and may choke on anything else (never tested this).

[rublev]

Apparently I already uploaded a script a while ago, in javascript. Wasn't aware of this and re-created it in Python. Well why not upload both then :)

Here you go: https://gist.github.com/bartvanandel/0418571bad30a3199afdaa1d5e3dbe25

The main limitation is that it only supports simple version semver-like specs, and may choke on anything else (never tested this).

Great thanks! Stumbled upon this thread naturally again when googling haha.