Support dependency groups

[rarkins]

e.g. upgrade angular and core angular dependencies (e.g. angular-touch) together.

[rarkins]

Need to think how to handle this when major updates occur. Although angular is trying to update all its core dependencies together, this is a rare case. Another example was Leaflet upgrading to 1.0 weeks/months before Mapbox supported it with their 3.x.

You could perhaps override the branch/PR name for these cases but I'm not sure you can reliably still support multiple PRs for major/minor upgrades (e.g. upgrade/angular-1.x and upgrade/angular-2.x)

[rarkins]

firebase and angularfire is another example of paired dependencies. However they usually can be upgraded separately.

[singapore]

This needs a solution not just for the branch name but also for PR title/body

[hutson]

angular and angular-mocks for Angular 1.x is a good example of paired libraries where they specifically treat what we would call minor versions in semantic versioning as breaking changes.

[rarkins]

@guumaster brought up a related example in #48 - eslint packages

Tain difference between the eslint example and angular example is that related eslint dependencies may take hours, days or weeks and not be released simultaneously like angular does.

There are a few obstacles to solving this issue, most important being:

• How such a feature interacts/conflicts with our existing feature to split major/non-major updates for each dependency
• How to name such a branch
• How to configure it elegantly

In the case of eslint, I guess it would be pretty simple to describe in written english, at least? e.g. "Put all dependencies starting with eslint into branch renovate/eslint, and name the PR 'Update eslint dependencies'"

Now to consider the edge cases:

• We probably stop supporting major/non-major separation of updates for eslint and related packages. e.g. no more renovate/eslint-foo-1.x and renovate/eslint-foo-2.x - eslint-foo-1.x updates would be ignored and only the latest (eslint-foo-2.x) versions added to renovate/eslint.
• What to do with eslint packages that dribble in later after you've already updated estlint itself and a few other dependencies? e.g. let's say the eslint PR has been merged by you, and finally eslint-bar updates itself. Would that also land into renovate/eslint even though it's the only update? I think it would need to, because otherwise it gets messy if more updates - including eslint itself - were to be subsequently updated.

[rarkins]

So one important question is: if we support dependency grouping (e.g. all angular together, or all eslint), then is it OK to disable major/non-major PR separation and instead always renovate to the latest?

I have tried thinking of ways to address this and still use major/non-major separation, but have not thought of an elegant approach yet. One idea was to support grouping using one dependency as the "parent" or "master" of others. e.g. that might be angular or eslint and then you allow other dependencies to piggyback. But if say we supported renovate/eslint-2.x and renovate/eslint-3.x it could be challenging to know what to do with other packages, e.g. a theoretical eslint-foo. We could try looking into the package.json peerDependencies for eslint-foo and developing logic for that, but (a) that seems complicated to link all this together, and (b) I wonder if it is also reliable?

Real-life example:
eslint-plugin-react has this:

"peerDependencies": {
    "eslint": "^2.0.0 || ^3.0.0"
  },

eslint-config-standard has this much more complicated one:

  "peerDependencies": {
    "eslint": ">=3.8.1",
    "eslint-plugin-import": ">=2.2.0",
    "eslint-plugin-node": ">=4.1.0",
    "eslint-plugin-promise": ">=3.5.0",
    "eslint-plugin-standard": ">=2.0.1"
  },

[rarkins]

#133 could also help with this. e.g. could define branchName at a per-package granularity.

[rarkins]

Waiting on #133