fix(pin): avoid pinning deprecated version

[djcsdy]

Closes #4608 (I think, not tested yet).

Looks like the problem was that renovate didn't take deprecation into account when determining the current version (fromVersion) of a dependency.

[djcsdy]

I ran renovate with this change against djcsdy/wildflower-codec and it did the right thing, so I think this is ready for merge.

 INFO: PR title changed (repository=djcsdy/wildflower-codec, dependencies=bitflags, branch=renovate/rust-pin-dependencies)
       "branchName": "renovate/rust-pin-dependencies",
       "oldPrTitle": "chore(deps): pin rust crate bitflags to =1.0.5",
       "newPrTitle": "chore(deps): pin rust crate bitflags to =1.0.4"

[rarkins]

I thought about this more and for npm, we should pin it to the same one as before, even if that one is deprecated. At the same time, I want to avoid any manager-specific code in this worker file because it should ideally be captured within lib/manager/*. Somehow we need a way to behave different for Cargo and npm here.

[rarkins]

Is this change required?

[djcsdy]

No, but it’s an unambiguous improvement since the function was already capable of returning null and it’s helpful for the type to document that fact.

At the moment strictNullChecks is turned off in tsConfig.json for compatibility with the parts of renovate that are still written in JavaScript, but as you convert more of the code to TypeScript you probably want to work towards turning this option on to get better static type checking.

[djcsdy]

Also I wanted to make it clear from the type of the function that

getFromVersion(config, rangeStrategy, nonDeprecatedVersions) ||
      getFromVersion(config, rangeStrategy, allVersions)

works because the first function call returns null if there are no matching non-deprecated versions.

[djcsdy]

I thought about this more and for npm, we should pin it to the same one as before, even if that one is deprecated. At the same time, I want to avoid any manager-specific code in this worker file because it should ideally be captured within lib/manager/*. Somehow we need a way to behave different for Cargo and npm here.

The behaviour with this change for Cargo and npm is:

1. If a lock file is present, pin to the version specified in the lockfile, don’t care if it is deprecated.
2. If there is no lock file, pin to the latest non-deprecated version that satisfies the version range, if possible. This is the same version that npm or Cargo would resolve in this case.
3. If there is no matching non-deprecated version, pin to the latest deprecated version that satisfies the version range.

Which part of this behaviour is not what you want for npm?

[rarkins]

@djcsdy thanks for the explanation. I hadn't realised about point (1) above.

[renovate-bot]

🎉 This PR is included in version 19.60.1 🎉

The release is available on:

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

Your semantic-release bot 📦🚀