Why Running yarn upgrade Does Not Update My package.json
Today I wanted to upgrade the dependency of React of one of my projects. So I r...
For further actions, you may consider blocking this person and/or reporting abuse
Nice article, but there is one little mistake that I found, which is:
yarn upgrade --lateston dependency"react": "^16.5.1": installs the latest version16.8.6as of today, and DOES NOT update package.json to"react": ^16.8.6". AS THE VERSION16.8.6IS ALREADY IN THE SPECIFIED RANGE^16.5.1Great write up 👏
I prefer to use
yarn upgrade-interactive --latestthankfully Oh My ZSH' Git plugin cones with a aliasyuiAnyway, upgrading interactive let's me see and selectively upgrade and it updates package.json as well 🥳
So this there?
This is what I'm trying to answer - I don't feel like this article reached a conclusion on this question... unless the answer is "no"?
yarn upgrade --latestdoes not respect version constraints - it installs the latest available versions, even if that conflicts with your constraints:"react": "^16.5.1"will change it to "react": "^18.2.0" which is not what I wanted.I just want to upgrade to the next compatible version and update my
package.json.That's not a thing?
(I'm about a week into
yarnand it's uber frustrating how many little ways it deviates fromnpm. I hate it. I wish it didn't exist. Why did we have to split the entire ecosystem in two like this? Becauseyarnused to be faster? ugh.)Okay, so I finally found the answer I was looking for:
yarn upgradewill respect your version constraints - as opposed toyarn upgrade --latest, which will most likely break everything.syncyarnlock will transfer the installed version numbers from
yarn.locktopackage.json, plain and simple - the--saveoption makes it write the changes back topackage.json, so you cangit diffand review the results, while--keepPrefixwill preserve the^or~operators in your existingpackage.jsonversion constraints.yarn installfinally will update youryarn.lockusing the updated version constraints - it won't install anything new at this point, but this step is required, or yarn will complain later that youryarn.lockis outdated with the new version constraints in your updatedpackage.json.That was fantastic, thanks!!
It's just a weird design of
yarn upgrade. Anyway thanks for your article which saved my day.I faced a bug because of the old dependencies. Tried
yarn upgrade, never get it to work.I finally upgraded all my versions in my package.json and solved my problem by removing the version range. And run:
yarn upgrade --latestthanks for the :
That's why yarn.lock is important...
...And are we getting react hooks soon?!
Yup, I had the same problem with
yarn upgrade.I solved this by mandating specific versions in
package.jsonso that there is no ambiguity about what version is installed.But the microversion number changes are supposed to be bug fix patches not expected to change behavior. You want to manage all those by hand? Seems tedious.
Have been using
yarn upgrade --exact. The flag forces the command to overridepackage.jsonno matter how the version constraint is declared.Actually, discovered that sometimes
package.jsonis not being updated.Looks like
yarn addis more reliable thanyarn upgrade:The downside it will install a new package if it has not been installed yet.
This technique can be used to upgrade all packages in a given scope:
Simply use
yarn upgrade allGreat if you just want to upgrade this 😉
Good article Wei!! Just clarified my doubt ;)
Saved my butt, thanks
POG solution, I was beating my head with this.