yarn upgrade-interactive doesn't update the package.json file

Created on 13 Sep 2017  ยท  13Comments  ยท  Source: yarnpkg/yarn

Do you want to request a feature or report a bug?

Bug

What is the current behavior?
yarn upgrade-interactive doesn't update the package.json with the selected version.

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

json "dependencies": { ... "body-parser":"1.18.0" }
I run yarn upgrade-interative and I choose upgrade body-parser to v1.18.1 or superior.

The package.json has the same version "1.18.0" on it.

What is the expected behavior?
I expect the same behavior I had on yarn v0.27.5: The package.json should update the dependencies' versions with the selected ones on upgrade-interactive process.

Please mention your node.js, yarn and operating system version.
node: 6.11.3
yarn: 1.0.2
OS: Ubuntu 16.04.3

triaged

Most helpful comment

But I'm installing a patch version and I want that patch in every installation. That should be in the package.json.

All 13 comments

Duplicate of #4390?

I have the same issue.

package.json

"devDependencies": {
     "chart.js": "^2.6.0",
     "vue": "^2.4.2"
}

Then I ran yarn upgrade-interactive and only updated chart.js to 2.7.0 and vue to 2.4.4

However package.json does not got updated. Only yarn.lock.

bildschirmfoto 2017-09-16 um 12 39 09

@apertureless why should it update your package.json in that case? Your semver versions ^2.6.0 and ^2.4.2 are still correct (you set a ^). With npm you wouldn't update both versions as well because the range is still correct for semver.

But I'm installing a patch version and I want that patch in every installation. That should be in the package.json.

You are getting the patch version @navarroaxel. Just look into your yarn.lock and you should see that version.

Update: I see that you are the issue creator and don't have a ^ in your package.json. This is different than the post from @apertureless... I only wanted to say that the semver behavior is different if a ^ is given ๐Ÿ˜‰

Hmm, so upgrade-interactive is supposed to, as of v1, respect your package.json semver range when offering a version to upgrade to. It seems like with an _exact_ version, it is not doing that, and that is a bug ๐Ÿž

I would expect upgrade-interactive to show you no available upgrade for body-parser (you are already on the latest version according to the semver range). Passing the -L/--latest flag would ignore the semver range and show you the latest version according to the registry.

Actually, this seems to be working as intended for me in Yarn 1.0.2. @navarroaxel could you include the output of the commands you ran?

This is my starting package.json

~/Projects/yarn-test : cat package.json
{
  "name": "yarn-test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "body-parser": "1.18.0",
    "left-pad": "^1.1.3"
  }
}

This is the incorrect behavior in v0.28.1. The version of body-parser is pinned at 1.18.0, so 1.18.1 is not a valid upgrade:

~/Projects/yarn-test : yarn upgrade-interactive
yarn upgrade-interactive v0.28.1
info Color legend :
 "<red>"    : Patch Update Backward-compatible bug fixes
 "<yellow>" : Minor Update backward-compatibles features
? Choose which packages to update. (Press <space> to select, <a> to toggle all, <i> to inverse selection)
 dependencies
โฏโ—ฏ body-parser  1.18.0  โฏ  1.18.1  https://github.com/expressjs/body-parser#readme

โœจ  Done in 5.41s.

And the corrected behavior in v1.0.2, respecting the semver range (pinned at exactly 1.18.0)

~/Projects/yarn-test : yarn upgrade-interactive
yarn upgrade-interactive v1.0.2
success All of your dependencies are up to date.
โœจ  Done in 0.27s.

And using the -L/--latest flag in v1.0.2 which ignores the semver range (so allows versions other than 1.18.0). Package.json is updated to 1.18.1 after the upgrade.

~/Projects/yarn-test : yarn upgrade-interactive --latest
yarn upgrade-interactive v1.0.2
info Color legend :
 "<red>"    : Major Update backward-incompatible updates
 "<yellow>" : Minor Update backward-compatible features
 "<green>"  : Patch Update backward-compatible bug fixes
? Choose which packages to update.
? Choose which packages to update. [email protected]
info Installing "dependencies"...
[1/5] ๐Ÿ”  Resolving packages...
[2/5] ๐Ÿšš  Fetching packages...
[3/5] ๐Ÿ”—  Linking dependencies...
[4/5] ๐Ÿ“ƒ  Building fresh packages...
[5/5] โ™ป๏ธ  Cleaning modules...
success Saved lockfile.
success Saved 5 new dependencies.
โ”œโ”€ [email protected]
โ”œโ”€ [email protected]
โ”œโ”€ [email protected]
โ”œโ”€ [email protected]
โ””โ”€ [email protected]
โœจ  Done in 11.58s.

~/Projects/yarn-test : cat package.json
{
  "name": "yarn-test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "body-parser": "1.18.1",
    "left-pad": "^1.1.3"
  }
}

Using yarn upgrade-interactive --latest on [email protected] the package.json in updated to the latest patch version, the side-effect depends on the --latest flag.

If this is the expected behavior I think we could close this issue.

Me too. Only updated the lock file rather than package.json

Same here

still a problem...

If someone's interested to investigate this bug and open a PR, it would make a great Hacktoberfest contribution :)

@navarroaxel @blade254353074 that is the expected behavior. It is somewhat specified in the RFC: https://github.com/yarnpkg/rfcs/blob/master/implemented/0000-upgrade-command-consistency.md

Without the --latest tag it respects your already specified semver (assuming you already put thought into the specified range) and will not change it unless --latest is specified.

If this is the expected behavior I think we could close this issue.

I left #4477 open as a feature request to also update the package.json range.

I'm going to close this issue for now as not updating package.json was intended. If you would make any supporting arguments for updating it over in #4477 I would appreciate it.

Was this page helpful?
0 / 5 - 0 ratings