Feature: install new peer dependencies requirements

[rarkins]

From @voxpelli on renovatebot/config-help#52:

See eg. this PR: voxpelli/node-micropub-express#26

It updates some eslint configs and the configs in those new major version require some new eslint plugins, but as the PR only adds the new major versions, and not their new additional requirement, the tests of course fail and merging the PR would result in a broken master.

and

version 8 of eslint-config-standard added two new peer dependencies:

eslint-plugin-node in standard/eslint-config-standard@62fd746#diff-b9cfc7f2cdf78a7f4b91a753d10865a2
eslint-plugin-import in standard/eslint-config-standard@b174d83#diff-b9cfc7f2cdf78a7f4b91a753d10865a2

And the Travis CI job fails as it tries to run the linting using plugins that are not there: https://travis-ci.org/voxpelli/node-micropub-express/builds/388885714

[rarkins]

I would rate this as quite challenging to implement. We'd need to calculate the peerDependencies before this PR, then the ones in the PR, and add the delta - at lot easier said than done.

[voxpelli]

@rarkins Could you give a pointer to where in the code one would start to solve this? If I find some time I might take on this challenge myself

[rarkins]

For now, we would keep this as an npm-specific feature so it would live somewhere in lib/manager/npm/*

Logically speaking it would come somewhere after the package.json updates - done in https://github.com/renovateapp/renovate/blob/master/lib/manager/npm/update.js - and before the lock file updating - done in https://github.com/renovateapp/renovate/tree/master/lib/manager/npm/post-update. The update code is intended to update one dependency in a package file at a time so is not really suitable - it seems like any check that the "final" package.json has correct peerDependencies needs to be done as part of postUpdate, once all the individual updates are complete.

There are some existing peerDependencies "nice to have" issues that might be good to consider or even implement beforehand:

• Validate peerDependencies #1864 : Validate peer dependencies
• #1432 : Automatically group peer dependencies

I think that #1864 would share a lot of logic with this issue, because it's also about asking the question "does this PR satisfy peer dependencies?". I can think of a few different approaches people might take if peerDependencies are missing:

1. Don't care/don't check (current behaviour)
2. Create the PR but include a failing status check to warn the user (essentially like Validate peerDependencies #1864)
3. Add the necessary peerDependencies (i.e. the idea of this issue)

[rarkins]

Also, I had considered that any such peer dependency check might be done with the help of npm and yarn, because both print some form of warning if there's an unmet dependency. However:

1. There's an open issue for yarn at least where some users disagree with yarn's classification of missing or not

2. This would come late in our logic (i.e. at lock file generation time) and make it hard to logically loop back again to update package.json and regenerate the lock file once more in order to implement your feature

As such, we might be better to implement this logic ourselves using raw npm registry results, although right now we are not saving the peerDependencies field in our regular npm datasource retrieval function.

Another point is how far deep/down do we go? e.g. do we only check for peer dependencies of our direct dependencies, or also of transitive/indirect ones?

[voxpelli]

As a first step I would say that we should only check for peer dependencies of our direct dependencies – that would probably solve 80% of the cases.

I agree that #1864 would probably be a good precursor to this one. When this issue is solved Renovate could try to avoid failing the #1864 validation, but there will still be cases where it will fail (eg. if someone is requiring a module that for some reason can't be used – eg. it hasn't been published or perhaps some other aspect of it is wrong)

[rarkins]

Closing as I still can't think of a way to feasibly do this

[voxpelli]

@rarkins I would still like to look into this and take a stab at implementing it. Would it be okay to keep it open a while longer?

[rarkins]

OK, but I suggest we discuss the scope/requirements first to make sure it’s not a solution that’s too difficult to merge or maintain.

[voxpelli]

Sure @rarkins 👍

This would be the scope, right?

Only work for npm/yarn and for them:

1. Detect current fulfillment of peer dependencies and fulfillment post-update
2. Validate that peer dependencies hasn't become less fulfilling, if they have, highlight that in the PR
3. After 2. has shown to be working well, automatically resolve peer dependencies as well