Support new rangeStrategy=in-range-only

[rarkins]

What would you like Renovate to be able to do?

Some people prefer to leave the package file unchanged and only do update-lockfile within the existing range.

If you have any ideas on how this should be implemented, please tell us here.

The results should essentially be like update-lockfile but discard any updates which need a change to the package file.

We should recommend against it in our documentation though, because it means people might end up multiple releases behind without knowing it.

Is this a feature you are interested in implementing yourself?

No

[olegkrivtsov]

I'd like to help with this one.

[olegkrivtsov]

My plan for fixing this issue:

1. Update lib/config/options/index.ts and describe the in-range-only strategy under the existing rangeStrategy option.
2. As the existing docs for update-lockfile says:

"update-lockfile = Update the lock file when in-range updates are available, otherwise replace for updates out of range. Works for bundler, composer, npm, yarn, terraform and poetry so far"

So, update the getNewValue() function in the above mentioned managers in lib/versioning. The function will always return currentValue.

For example, for composer:

renovate/lib/versioning/composer/index.ts

Lines 135 to 145 in 9b2c4b5

	if (rangeStrategy === 'update-lockfile') {
	if (matches(newVersion, currentValue)) {
	return currentValue;
	}
	return getNewValue({
	currentValue,
	rangeStrategy: 'replace',
	currentVersion,
	newVersion,
	});
	}

if (rangeStrategy === 'in-range-only') {
      return currentValue;
}

3. Update lib/workers/repository/process/lookup/index.ts:

renovate/lib/workers/repository/process/lookup/index.ts

Lines 164 to 175 in 9b2c4b5

	rangeStrategy === 'update-lockfile' &&
	!lockedVersion
	) {
	rangeStrategy = 'bump';
	}
	const nonDeprecatedVersions = dependency.releases
	.filter((release) => !release.isDeprecated)
	.map((release) => release.version);
	let currentVersion: string;
	if (rangeStrategy === 'update-lockfile') {
	currentVersion = lockedVersion;
	}

Ensure new range strategy is taken into account here.

4. Update lib/workers/repository/process/lookup/generate.ts:

renovate/lib/workers/repository/process/lookup/generate.ts

Lines 67 to 69 in 9b2c4b5

	if (rangeStrategy === 'update-lockfile' && currentValue === update.newValue) {
	update.isLockfileUpdate = true;
	}

Ensure new range strategy is taken into account here.

[rarkins]

If rangeStrategy=in-range-only then you need to behave like update-lockfile but discard any updates where newValue !== currentValue.

[timnolte]

I'd be happy to test this out, though I'm not quite sure how to do that. I have an example repository setup where I would want it to function like this.

[renovate-release]

🎉 This issue has been resolved in version 31.63.0 🎉

The release is available on:

• GitHub release
• 31.63.0

Your semantic-release bot 📦🚀

[timnolte]

Hmm, so this feature appears to not update everything "in range". I have the following in my composer.json

"johnpbloch/wordpress": "~5.5.0",
"johnpbloch/wordpress-core": "~5.5.0",

The current version in the lockfile is

"johnpbloch/wordpress": "5.5.1",
"johnpbloch/wordpress-core": "5.5.1",

And the latest version of 5.5.x is 5.5.8 which will update when I issue a standard composer update.

  - Upgrading johnpbloch/wordpress (5.5.1 => 5.5.8)
  - Upgrading johnpbloch/wordpress-core (5.5.1 => 5.5.8)

With the setup of using in-range-only I'm not seeing any attempt to update these packages.