Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`yarn upgrade-interactive` does not update package.json #4390

Closed
alexdevero opened this issue Sep 11, 2017 · 38 comments

Comments

Projects
None yet
@alexdevero
Copy link

commented Sep 11, 2017

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

This comment has been minimized.

Copy link

commented Sep 11, 2017

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

@blobor

This comment has been minimized.

Copy link

commented Sep 11, 2017

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

@kaylie-alexa

This comment has been minimized.

Copy link
Member

commented Sep 12, 2017

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

This comment has been minimized.

Copy link
Author

commented Sep 12, 2017

@kaylieEB thank you for explanation.

@f

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2017

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

This comment has been minimized.

Copy link
Member

commented Sep 12, 2017

@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 comment has been minimized.

Copy link

commented Sep 15, 2017

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

yarn upgrade --latest
@SenHeng

This comment has been minimized.

Copy link

commented Sep 28, 2017

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

This comment has been minimized.

Copy link
Author

commented Sep 29, 2017

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

@SenHeng

This comment has been minimized.

Copy link

commented Sep 29, 2017

@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

This comment has been minimized.

Copy link
Author

commented Sep 30, 2017

@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

This comment has been minimized.

Copy link

commented Sep 30, 2017

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

@alexdevero

This comment has been minimized.

Copy link
Author

commented Oct 1, 2017

@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

This comment has been minimized.

Copy link

commented Oct 4, 2017

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 pkg-b@2.1.0 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

This comment has been minimized.

Copy link
Author

commented Oct 4, 2017

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

@scharf

This comment has been minimized.

Copy link

commented Oct 9, 2017

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:

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 comment has been minimized.

Copy link

commented Nov 20, 2017

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

This comment has been minimized.

Copy link
Member

commented Nov 20, 2017

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? 😉

@Noiwex

This comment has been minimized.

Copy link

commented Nov 27, 2017

Yes, the same happens with upgrade. It only works properly if you have --latest argument.

@danieledler

This comment has been minimized.

Copy link

commented Jan 4, 2018

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

This comment has been minimized.

Copy link

commented Jan 11, 2018

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

This comment has been minimized.

Copy link

commented Jan 11, 2018

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

This comment has been minimized.

Copy link

commented Jan 15, 2018

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

@Noiwex

This comment has been minimized.

Copy link

commented Jan 16, 2018

@bartvanandel

This comment has been minimized.

Copy link

commented Jan 16, 2018

@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

This comment has been minimized.

Copy link

commented Mar 15, 2018

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

This comment has been minimized.

Copy link

commented Mar 25, 2018

@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

This comment has been minimized.

Copy link

commented Apr 6, 2018

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

@StefanoVollono

This comment has been minimized.

Copy link

commented Apr 10, 2018

same issue for me today

@rafaelrinaldi

This comment has been minimized.

Copy link
Contributor

commented May 3, 2018

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

@marcofugaro

This comment has been minimized.

Copy link

commented May 21, 2018

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

@murbanowicz

This comment has been minimized.

Copy link

commented Dec 20, 2018

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

This comment has been minimized.

Copy link

commented Mar 18, 2019

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

@lostpebble

This comment has been minimized.

Copy link

commented Mar 18, 2019

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

This comment has been minimized.

Copy link

commented Mar 18, 2019

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

@tuurbo

This comment has been minimized.

Copy link

commented Mar 18, 2019

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

@grigio

This comment has been minimized.

Copy link

commented Mar 18, 2019

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

@lostpebble

This comment has been minimized.

Copy link

commented Mar 18, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.