packages peer dependencies ignored when suggesting updates

[clayreimann]

For example chai-as-promised@5.0.0 has a peer dependency of chai >= 2.1.2 < 3 but after checking for updates chai@3.0.0 was suggested.

[raineorshine]

I am not familiar with how peerDependencies work, so I will have to investigate. Should npm-check-updates ignore peerDependencies? Any suggestions you have are appreciated.

[clayreimann]

peerDependencies specify other packages that need to be present but aren't required directly from the current package.

npm-check-updates should account for this when it recommends updated versions of the package.

in my example npm-check-updates suggested that I update to chai@3.0.0, however doing so broke chai-as-promised@5.0.0 because it was expecting chai > 3.0.0

[mathieumg]

it was expecting chai > 3.0.0

I imagine you meant < 3?

[clayreimann]

That's the one

[oztune]

This feature would be great to have. I just spent about 10 minutes trying to figure out what's going on with something I'm working on and this would have caught it immediately.

As far as functionality, I can't see why it shouldn't treat peer dependencies exactly the same as regular or dev dependencies.

[christophehurpeau]

:+1:

[raineorshine]

The purpose of npm-check-updates is to suggest breaking changes. If it didn't, we would just use npm update.

Even if you make a sensible argument for certain constraints on peer dependencies I would be resistant to implementing it as it changes that fundamental purpose of npm-check-updates: to show you the latest versions, disregarding version numbers while preserving version patterns.

It's a bit counterintuitive since the purpose of npm itself is the opposite: to prevent breaking changes.

Regarding the suggestion to update peerDependencies themselves, this is not recommended due to another counterintuitive aspect of peerDependencies: you want peerDependencies to be as loose as possible. If your module is compatible with OtherModule v1.x, then changing the dependency to v3.x would suddenly warn that it was incompatible with earlier versions, even if it was compatible. Just because there is a breaking change doesn't mean that the entire API has changed. Thus, incompatibilities between peer dependencies must be manually resolved by a human anyway.

It is unfortunate that peerDependencies are so problematic.

[clayreimann]

@metaraine That's a fair point. I guess I am just used to npm-check-updates not actually breaking anything. :stuck_out_tongue_winking_eye:

[jehy]

Why not suggest peer updates instead of doing them? It won't break anything but will be very useful. Because now I have to move peerDependencies to devDevdependencies, update them with ncu and then move back...

[raineorshine]

@jehy I added the --peer option and published to v2.12.0. Let me know if that works!

[jehy]

Hi, @raineorshine! Thanks for the option, I updated to 2.12.0 but it does not seem to work. My package.json:

{
  "name": "xxx",
  "version": "3.0.3",
  "description": "xxx",
  "main": "index.js",
  "scripts": {
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "amqp": "^0.2.6",
    "bluebird": "^3.5.0",
    "body-parser": "^1.17.1",
    "clone": "^2.1.1",
    "exec": "^0.2.1",
    "express": "^4.15.2",
    "express-pass-id": "^0.0.2",
    "knex": "^0.13.0",
    "logfox": "^0.2.15",
    "mask-sensitive": "0.0.4",
    "moment": "^2.17.1",
    "mongodb": "^2.2.24",
    "node-tlv": "^1.5.5",
    "object-assign": "^4.1.1",
    "pg": "^6.1.4",
    "raw-body": "^2.2.0",
    "request": "^2.81.0",
    "request-promise": "^4.2.1",
    "simple-promise-queue": "^0.1.7",
    "sprintf-js": "^1.0.3",
    "tlv": "^1.1.1",
    "trim-left-zero": "0.1.0",
    "underscore": "^1.8.3",
    "validator": "^7.0.0"
  },
  "peerDependencies": {
    "babel-cli": "^6.23.0",
    "babel-preset-es2015": "^6.22.0",
    "eslint": "^3.16.0",
    "eslint-config-airbnb": "^14.1.0",
    "eslint-plugin-import": "^2.2.0",
    "eslint-plugin-jsx-a11y": "^4.0.0",
    "eslint-plugin-promise": "^3.4.2",
    "eslint-plugin-react": "^6.10.0",
    "eslint-plugin-standard": "^2.0.1"
  },
  "devDependencies": {
    "mocha": "^3.2.0"
  }
}

When I use ncu --peer, I get

Using /web/processing/pmv3-processing-App/package.json [..................] - : mask-sensitive 0.0.4 → 0.0.6

The following dependencies are satisfied by their declared version range, but the installed versions are behind. You can install the latest versions without modifying your package file by using npm update. If you want to update the dependencies in your package file anyway, run ncu -a.

mongodb ^2.2.24 → ^2.2.29 pg ^6.1.4 → ^6.4.0 validator ^7.0.0 → ^7.1.0

Run ncu with -u to upgrade package.json

but if I move my peerDependencies to devDependencies, I see that there are packages which should be updated (all eslint*):

Using /web/processing/pmv3-processing-App/package.json [..................] - : mask-sensitive 0.0.4 → 0.0.6 eslint ^3.16.0 → ^4.1.1 eslint-config-airbnb ^14.1.0 → ^15.0.1 eslint-plugin-jsx-a11y ^4.0.0 → ^5.0.3 eslint-plugin-react ^6.10.0 → ^7.1.0 eslint-plugin-standard ^2.0.1 → ^3.0.1

The following dependencies are satisfied by their declared version range, but the installed versions are behind. You can install the latest versions without modifying your package file by using npm update. If you want to update the dependencies in your package file anyway, run ncu -a.

mongodb ^2.2.24 → ^2.2.29 pg ^6.1.4 → ^6.4.0 validator ^7.0.0 → ^7.1.0 eslint-plugin-import ^2.2.0 → ^2.6.0

Run ncu with -u to upgrade package.json

[raineorshine]

@jehy Ack! You are right! It even got around my unit test. I wasn't passing the --peer flag through correctly.

Try v2.12.1 :)

[jehy]

Yup, 2.12.1 works just as supposed, thanks!

[raineorshine]

👍

[kushmisra]

Hi, i just wanted to inquire about what ncu would do if i run it in the following scenario,

suppose my package.json looks something like this:

"dependencies": { "X": "^0.2.6", "Y": "^3.5.0", "Z": "^1.17.1", "A": "^2.1.1", "B": "^0.2.1", }

and dependency "A" has specified a peer dependency on X as: "peerDependencies": { "X": "^2.3.0", "Y": "^3.5.0" }

so if i run NCU on this , will the updated package result returned to me take the peer dependency issue into account , and suggest me to upgrade X to ^2.3.0 ?

[raineorshine]

Currently ncu does not take peerDependencies into account. It is harder than it looks and handling them automatically is not obviously the correct choice, as I described in https://github.com/tjunnone/npm-check-updates/issues/80#issuecomment-177314213.

(Side note: If X is a dependency, then it doesn't need to be a peerDependency.)

There is certainly value in notifying the user about broken peerDependencies. I could even see an optional flag to only upgrade packages in a way that doesn't break peerDependencies. These could be good enhancements. But I remain cautious about complicating the logic of ncu. "Smarter" logic has already proved to be wrong in cases such as taking into account installed dependencies (incredibly confusing for new users of ncu).

The purpose of ncu is to break your code and peerDependencies by upgrading them to the latest. This would be the most intuitive stance to adopt.

[raineorshine]

Yes, that is correct. On Thu, Jul 5, 2018 at 12:20 AM kushmisra notifications@github.com wrote:

Thanks @raineorshine https://github.com/raineorshine !. and yes its harder than it appears. So, just for confirmation , currently using --jsonAll or --jsonUpgraded will give me packages such that it may break the peerDependencies. So just blindly using the package.json suggested by the above flags can infact break my code , due to peerDependencies mismath ?

The problem due to which this issue was raised ie:-

For example chai-as-promised@5.0.0 has a peer dependency of chai >= 2.1.2 < 3 but after checking for updates chai@3.0.0 was suggested.

this will still exist with the result i get after using ncu?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tjunnone/npm-check-updates/issues/80#issuecomment-402617701, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtyxPW5gZgHlQVXphAJtBqQI1ZEWnAZks5uDbAmgaJpZM4E4U8a .

[kopax]

I have the same issue.

My peerDependencies gets updated when I run ncu -u, I expect them not to move. Is there now a fix, I am using latest v3.

Would be cool to have a --ignore-peer options. We can't force all our users to upgrade every time we type ncu -u, that's a bad behavior for every package maintainer, which want to support the widest semver range versions for it's peer dependencies.

[raineorshine]

@kopax You can effectively ignore peerDependencies with ncu --dep dev,prod (dev,prod,optional,bundle if needed)

[kopax]

How can I only update prod and dev ? is it ncu --dep dev,prod ? is there a shorthand ?

[raineorshine]

Yes, it is ncu --dep dev,prod. You would need to create an alias if you want it shorter.

[kopax]

Ok. I now got it, this module is really helpful, thanks!

[kopax]

@raineorshine sorry to be struggling that much, I am typing:

ncu --dep dev,prod and it does not write into package.json.

I have also tried ncu --dep dev,prod -u but then peerDependencies get updated.

-w is simply not working anymore since v3, any idea how I can perform upgrade, skip peer and write to package.json?

[raineorshine]

@kopax I tried the command ncu --dep dev,prod -u verbatim and it worked correctly for me. It only updated dependencies and devDependencies and not peerDependencies. If you can provide a package.json that is able to reproduce the bug, I would be happy to investigate more!