fix(manager/custom): Support range strategy with custom managers

[mpkorstanje]

Changes

Ensures getRangeStrategy does not return null when a custom manager is used. Thus enabling the use of range strategies with custom managers.

Note: custom manger do not support setting a range strategy, but the range strategy can be set through package rules for a specific manager. For example:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "description": "Parse Ruby Gemspec files",
  "extends": [
    "config:recommended"
  ],
  "customManagers": [
    {
      "customType": "regex",
      "fileMatch": [
        "^.*\\.gemspec"
      ],
      "matchStrings": [
        ".*\\.add_(:?(?<depType>.*?)_)?dependency\\s*(['\"])(?<depName>[^'\"]+)(['\"])(\\s*,\\s*(?<currentValue>(['\"])[^'\"]+['\"](\\s*,\\s*['\"][^'\"]+['\"])?))?"
      ],
      "datasourceTemplate": "rubygems",
      "versioningTemplate": "ruby"
    }
  ],
  "packageRules": [
    {
      "description": "Applies \":preserveSemverRanges\" to the custom above manager. See: https://github.com/renovatebot/renovate/discussions/28090",
      "matchDatasources": [
        "rubygems"
      ],
      "matchManagers": [
        "custom.regex"
      ],
      "rangeStrategy": "replace"
    }
  ]
}

Context

• Fixes: Unsupported range strategy when using custom manager with ruby versioning #28090

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[viceice]

otherwise LGTM

[ysangkok]

It sounds good that getRangeStrategy would be prevented from returning null. But it seems from the PR that there is nothing preventing a manager from returning auto, which, if I understand correctly, would then reach the versioning code. This isn't supposed to happen: #33142 (comment).

If Renovate has custom managers returning auto, and custom managers then only work for versioning that accepts auto, custom managers would, of course, only work for versioning that actually implements auto, which isn't all of them (I know PVP doesn't implement it). So to make it work for all, we then have to duplicate the conversion logic (from auto into the actual non-auto strategy) in versioning and in managers (which usually decide the range strategy). This isn't ideal.

So, what are the ways to effectively avoid requiring all versioning modules to implement auto conversion logic (in addition to having it in managers)?

• This PR seems like a good opportunity to ensure that a custom manager never fails to commit to non-auto versioning strategy, like all other managers do. There could be an error in the case that no non-auto range strategy is provided by the manager. This is what I propose is added to this PR.
• Another option would be to remove getRangeStrategy from managers entirely, but that seems like a much larger chance. The logic would only be in versioning, and this PR could stay unchanged.
• Maybe I have misunderstood something, and this PR does prevent auto from reaching versioning somehow? I'd like to hear how.

CCing @rarkins since he also seems to think that auto should never be sent to versioning's getNewValue (in the thread linked above)

[RahulGautamSingh]

But it seems from the PR that there is nothing preventing a manager from returning auto

Custom managers do not have the getRangeStrategy function implementation, yet. So, we will always fallback to the global rangeStrategy value or the rangeStrategy value set using package rules.

And, there's an if-check in the manager/module/index -> getRangeStrategy function which will convert auto -> replace in such cases. code below

renovate/lib/modules/manager/index.ts

Lines 92 to 98 in ff0af5f

	}
	if (rangeStrategy === 'auto') {
	if (m.updateLockedDependency) {
	return 'update-lockfile';
	}
	// default to 'replace' for auto
	return 'replace';

If one day, we would like to support range strategies for cusstom managers then we just need to move conversion logic from auto -> replace in that PR. This PR does not need to handle that, I think.

[renovate-release]

🎉 This PR is included in version 39.144.2 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)
• 39.144.2

Your semantic-release bot 📦🚀

[rarkins]

I am reverting this PR due to multiple problems raised by users: #34083