Update packages respecting semver ranges in package.json

[rjokelai]

Is there a way to update packages only to the semver ranges as specified in package.json?

Running yarn up '**' seems to override all the versions in the package.json with the --latest one. The closes equivalent I've found so fa is keeping the caret version such as ^4.0.0 in package.json, removing the yarn.lock file and rerunning yarn install. This recreates the lockfile with the latest semver compatible with ^4.0.0, e.g., 4.3.1.

Example:

{
  "name": "yarntest",
  "version": "1.0.0",
  "packageManager": "[email protected]",
  "dependencies": {
    "history": "^4.0.0"
  }
}

will have the following in the lockfile:

"history@npm:^4.0.0":
  version: 4.0.0
  resolution: "history@npm:4.0.0"

Running yarn up does nothing. Running yarn up -C history upgrades the package to version ^5.3.0 in both package.json and yarn.lock. However, deleting the lockfile and running yarn will give me this in the lockfile:

"history@npm:^4.0.0":
  version: 4.10.1
  resolution: "history@npm:4.10.1"

[jlherren]

TL;DR: The answer is: yarn up -R '**'

Thank you for asking this question! ❤️ I struggled with the exact same question for the last almost 2 years of using Yarn 2+ and never found a solution. I find the documentation to be severely lacking on this topic. Your question above triggered me into finding the answer.

What you basically want is the Yarn 2+ equivalent of what yarn upgrade did in Yarn 1 (ignoring workspaces). The migration guide just says that yarn upgrade is now yarn up with no further explanation. yarn up alone does nothing, because a list of packages to update must be provided as arguments. If nothing is provided, then nothing is updated. Indeed, very confusing.

Your solution of doing rm yarn.lock && yarn install is fully valid and I did the same until now.

From reading the documentation I always believed that yarn up -R '*' should work, but it only upgraded some packages, not all of them. Seeing the double asterisk in your question enlightened me: Specifying * will only upgrade packages that do not contain / in the package name, while ** upgrades them all. Presumably, the matching uses glob-style wildcards, where a single * cannot match a /.

[arcanis]

Presumably, the matching uses glob-style wildcards, where a single * cannot match a /.

Yep; we have an issue open on minimatch about that: micromatch/micromatch#219

Perhaps we can workaround it by replacing the / by another character like \x01 before running the match?