Npm-check-updates: `peerDependencies` interfering with update of `devDependencies` of same name

[brettz9]

• [x] I have read the list of known issues before filing this issue.

• [x] I have searched for similiar issues before filing this issue.

• node version: 10.16.3

• npm version: 6.12.0
• npm-check-updates version: 3.1.25

---

On attempting to update the package eslint-plugin-chai-friendly (see https://github.com/ihordiachenko/eslint-plugin-chai-friendly/blob/master/package.json ), the presence of its peerDependencies seems to prevent the same (eslint) devDep. being found for upgrade in ncu -u

[raineorshine]

I can't say for sure, but I would guess that having different versions of the same dependency specified in dependencies and peerDependencies is either not recommended and/or has ill-defined behavior. When testing this myself, it appears that the dependencies version takes precedence.

So my first recommendation is for the package owner to have a single eslint dependency in the dependencies section.

That said, npm-check-updates does not mirror the default npm behavior, and instead seems to only check peerDependencies, so I will mark this as a bug.

[brettz9]

I think the reason why dependencies (or actually devDependencies, as I wouldn't expect dependencies to co-exist with peerDependencies since the purpose of the latter is to indicate a package should load the peer deps. itself) takes preference is because one may wish to support older versions (i.e., in peerDependencies), but when performing one's tests, use the most up-to-date version in devDependencies.

In this case, we let people use older versions of eslint if they wish (esp. since it can be troublesome to upgrade), but ensure we are testing with the latest version ourselves.

[mikestopcontinues]

I'm having this issue as well. I need to test my package with devDependencies, but when I deploy, I need end-users to use peerDependencies. I think they should definitely be handled separately.

[bugzpodder]

same here, devDependencies is needed for local testing. i have peerDepenedencies at package: ^2.0.0 and devDepenedencies at package: 2.3.1 and ncu can't handle this.

[brettz9]

Note that as a workaround, one can do something like this in .ncurc.js:

module.exports = {
  // Whitelist all for checking besides `peer`:
  "dep": "prod,dev,optional,bundle"
};

[mesqueeb]

I would say, since peerDependencies are not installed in your node_modules, you still need to add it to the devDependencies because you'll probably need it to run your tests.

So I think in 90% of the cases, people would have the same packages in peer and dev dependencies.

I'd like to keep them the same version at all times, when I upgrade one, also upgrade the other. Just to prevent anything breaking, because not everyone keeps to semver...

[brettz9]

@mesqueeb : While one should install in devDependencies, allowing lower versions (as well as higher version) in peerDependencies allows your consumers to keep using older versions.

For example, we do not want to give warnings to everyone using our eslint plugin to upgrade immediately to the latest version of our peerDep, eslint (by forcing peerDependencies to only support the latest eslint version), but we do want to use the latest eslint ourselves (using Travis to conditionally downgrade when we also want to check older peerDep (eslint) versions).

I'd be ok with peerDeps. being auto-updated to add the latest version though (e.g., expanding a current range).