Raise PRs for out-of-range dependencies

[Crashthatch]

I am using renovate primarily to do regular lock file maintenance. I prefer to keep my accepted dependencies in package.json as wide as possible so I can dedupe more successfully and minimize the use of different versions of a library. I have lock file maintainance turned on, and am happy with package.json containing ^2.3.4 of a dependency for which 2.3.6 has been released (lock file maintenance will update package-lock to lock to 2.3.6, but package.json will not be affected and my project will remain compatible with all versions ^2.3.4).

I also like renovate's functionality to raise PRs when my project has a dependency that IS out of date. eg. when 3.0.1 of the dependency is released (out of the range of ^2.3.4), raising a PR alerts me that there's a new version and I should upgrade if possible.

I have looked at all the config options of renovate and experimented, but I don't seem to be able to be able to find a way to do this. If I enable renovate for all major, and keep it disabled for minor and patch, it will generate a PR for the above example, but miss where package.json specifies using a ~ or exact version. If I enable renovate for minor, it will generate PRs for the above example, and try to make a PR which changes package.json.

I think I could create renovate rules for each dependency which tell renovate which major/minor/patch of this dependency I want to create PRs for, but this information is already specified in my package.json (that's exactly what ^, ~ etc. means!), and it seems redundant & error-prone to specify it in two places.

Is there a way to accomplish this? Have others been in this situation? Should I give up trying to use package.json to control my dependencies and just specify it all in renovate.json and use pinned-versions instead (Doesn't this make deduping transitive dependencies difficult)?

[rarkins]

@Crashthatch could you give me some examples of what you mean, and what your current config is? I'm not sure I definitely understand.

[rarkins]

By the way, I think what you want is likely possible and you definitely shouldn't be forced into pinning dependencies of a library for Renovate's sake.

[Crashthatch]

For example, my config:

package.json:

dependencies: {
    "dep1": "~1.0.0",
    "dep2": "^1.0.0"
}

renovate config A:

{
  "extends": [
        "config:base",
        "schedule:earlyMondays"
      ],
    "pinVersions": false
}

Let's assume that v1.1.0 of dep1 and dep2 are now released. With config A, dep1 is now out of date (the latest version of dep1 is outside the range I specified, so will never be used), and I want a PR to alert me to this and try to change package.json to:

dependencies: {
    "dep1": "~1.1.0",
    "dep2": "^1.0.0"
}

However, what I actually get is 2 PRs, one for updating dep1 to ~1.1.0 and the other for updating dep2 to ^1.1.0. I don't want this second PR because 1.1.0 is still within the range ^1.0.0 specified in my original package.json, and so no changes are required to package.json for dep2. I want to keep the dep2 range as wide as possible to allow backwards compatibility in case dep2@1.0.0 is installed for other reasons (eg. a project that depends on my project has their own direct dependency on dep2@1.0.0).

I mentioned package-lock in my original post, but actually I think that's a red-herring: the lock file is being maintained correctly (after the release of 1.1.0 the lockfile will correctly pin dep1 to 1.0.0 and dep2 to 1.1.0 until package.json is changed to allow later versions of dep1 if / when I decide to widen the allowed range).

[rarkins]

@Crashthatch what you describe as your desired behaviour is also the expected behaviour. I just ran a test and found it's behaving as expected: https://github.com/renovate-tests/range1

Are you sure you didn't also enable the setting inRangeUpdates? That setting would produce the ^1.1.0 PR like you describe.

pinVersions is actually now a deprecated setting, but it gets migrated and handled fine. The preferred setting now is rangeStrategy: https://renovatebot.com/docs/configuration-options/#rangestrategy

In short: Renovate is intended to behave exactly as you describe, and seems to be when I replicate your config

[Crashthatch]

Ok, that's reassuring. Yes, you're right, that test repo is doing exactly what I want. I must be mistaken about the behaviour I saw. I will apply that config to my repos and monitor (it only runs once a week, so will take a while for me to test).

Thanks for the help, sorry for the false report!

[rarkins]

No problem, maybe when you originally observed there was a temporary bug that went away. Please reopen if it repeats or you have any other questions.