latest is not supported as a valid version spec for dependencies in a package.json file

[rcalfredson]

This could be considered either a bug or feature request, so please feel free to re-categorize as you see fit!

What Renovate type are you using?
Renovate CLI

Describe the bug
If latest is specified as the version of a dependency in a package.json file, then that dependency is given a skipReason of unknown-version and is ignored by renovate, even though lockedVersion is correctly detected.

Did you see anything helpful in debug logs?
Example:

{ depType: 'devDependencies',
    depName: '@marketplace-engineering/eslint-config-marketplace',
    currentValue: 'latest',
    skipReason: 'unknown-version',
    prettyDepType: 'devDependency',
    lockedVersion: '5.2.0' }

Please note I am not able to link directly to GitHub because the example in question comes from enterprise code, and is associated with a repo in a private registry.

To Reproduce
Steps to reproduce the behavior:

1. Create repository with at least one dependency with version spec set to latest
2. Run renovate CLI on the repo and observe that this dependency is ignored.

Expected behavior
latest is recognized and supported as a valid version specification in a package.json file. There is value in supporting latest spec in my opinion, for this reason: a dependency might have a new release, and a downstream project will not pick up that change until there would be an update to its package-lock.json. Thus, if the "latest" version used by some downstream repo has a vulnerability, then we should be able to detect it and update the lockfile using renovate.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[rarkins]

In general we avoid "open" ranges like * or latest equivalents in any manager, but we should reconsider this when there's the possibility to bump a lockfile.

[HonkingGoose]

In general we avoid "open" ranges like * or latest equivalents in any manager, but we should reconsider this when there's the possibility to bump a lockfile.

@rarkins Did we get the ability to bump lockfiles already? Or are we still waiting on something?

[rarkins]

Yes, we did

[bmulholland]

Circling back around to this and I see my previous message was hidden. Message received, sorry for the small rant :). I hope this is on-topic enough, please let me know if there's a better place to ask. And if the docs address this question, please point me to them (I've looked extensively!)

If renovate does not support "latest," what should I replace it with, while still maintaining the signal, in a single place, that some versions are pinned for a reason?

Specifically: We use "latest" to indicate "upgrade these freely" and a set version to indicate "we know later versions are broken." That's usually still a range, e.g. "<14", because that semantically indicates "we don't support v14." We then keep docs on all set versions (non-latest) with either a ticket number or an explanation (e.g. "requires vue 3"). This strategy works very well with e.g. yarn upgrade: we get an upgrade for all packages we haven't set. If tests fail, we figure out why, file a ticket and mark the range in package.json, and return to it when we can.

As this issue indicates, the same strategy does not work with renovate. We'd have to change all our "latest" indicators to at least a range, which drowns out the signal: if all versions are set in some way, then the ones that are important do not stick out. And the only place the "do not upgrade" signal is stored is in the fact that there's a closed PR. This is compounded by the fact that package.json doesn't support comments, so we couldn't indicate "this version pin actually matters." We could create a separate documentation page, but that's decoupled from the actual file and therefore is guaranteed to fall out of date. We could create a ticket in our issue management tool, but those inevitably get drowned out in noise.

Or am I missing something else entirely?

[rarkins]

First of all in Renovate terminology, we should be able to support latest values combined with rangeStrategy=update-lockfile. It's hopefully not a lot of code/complexity to support that.

Back to your specific scenario, in general I'd say latest is not the best choice for most dependencies because you can be "broken" by any future major release, if it contains breaking changes which affect you. I'd recommend sticking to a major range like ^1.0.0 or 1.* so that you can control when you take a new major release. Is there anything I'm missing for why latest is preferable?

In my opinion what you describe as indicators is a kind of internal convention, not a standard. It might be a great idea, maybe even "mature", but that doesn't mean it's a standard or that Renovate should be able to guess what you are doing out of the box. I have no philosophical objection to anything you wrote though, or finding a way for Renovate to support it.

Regarding your indicators, you can have several without them being latest, e.g. pinned 1.0.0, minor range ~1.0.0, major range ^1.0.0, which could indicate bad compatibility, ok compatibility, and good compatibility.

More importantly though, what would you like Renovate to do with these indicators? e.g. you want certain ones to never be upgraded, and everything else upgraded? etc

[bmulholland]

Ah, I just tried rangeStrategy=update-lockfile, but I guess your comment was actually that it could be supported, not that it is? It doesn't appear to work right now. Too bad.

what would you like Renovate to do with these indicators? e.g. you want certain ones to never be upgraded, and everything else upgraded? etc

This is indeed the heart of it. Renovate should update all packages with a "latest" indicator, and packages within a pin (e.g. I'd use "<13" and want all upgrades on the v12 release, such as security fixes). But the pins are there for a reason, and I wouldn't want them changed. Mentally model it this way: instead of closing a renovate PR, I pin the version in package.json. The package.json becomes the configuration that tells renovate which packages we want it to upgrade, and which not.

[rarkins]

You have created your own personal/company convention, and it sounds quite clever - but these are custom conventions and not part of the npm or semver standard. But that does not mean Renovate can guess and comply to your convention off the shelf. There's kind of two parts here:

1. Nothing should stop us supporting latest as a valid constraint, i.e. equal to *
2. You can use matchCurrentValue with regex to match your conventions like /^</ and then apply rules that way

[bmulholland]

it sounds quite clever

Can you explain what you mean by this? What's "clever" about it? Did you mean the term as a compliment?

Nothing should stop us supporting latest as a valid constraint, i.e. equal to *

This sounds reasonable. What are next steps, and how can I help?

[rarkins]

it sounds quite clever

Can you explain what you mean by this? What's "clever" about it? Did you mean the term as a compliment?

Yes

Nothing should stop us supporting latest as a valid constraint, i.e. equal to *

This sounds reasonable. What are next steps, and how can I help?

Submit a PR affecting lib/modules/versioning/npm so that latest is treated the same as *. Also test it against a "real" repo to make sure the result is like you want it.

[github-actions]

Hi there,

Get your issue fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this.

To get started, please read our guide on creating a minimal reproduction.

We may close the issue if you, or someone else, haven't created a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.

Good luck,

The Renovate team

[rarkins]

We need an example repo to test against where the package.json contains latest while there is an update for the dependency pending