Cooldown does not upgrade to a newer version that is not latest

[k3nsei]

• I have searched for similar issues

---

Steps to Reproduce

Running npx -y -- npm-check-updates --dep=dev,optional,peer,prod,packageManager --cooldown=2 does not update Svelte Kit to a newer version that is not the latest, as latest is not 2 days old.

The issue is with the --cooldown option: it currently only allows updating to the latest version, but only if the package hasn’t been updated in the last 2 days. It does not update to a version that is newer than the current one but older than the latest.

Dependencies:

{
  "devDependencies": {
    "@sveltejs/kit": "2.22.5"
  },
  "packageManager": "pnpm@10.17.1",
  "volta": {
    "node": "24.8.0",
    "pnpm": "10.17.1"
  }
}

Steps:

Run npx -y -- npm-check-updates --dep=dev,optional,peer,prod,packageManager --cooldown=2 -u

Current Behavior

Svelte Kit isn't updating to version older than latest but newer that the one specified in package.json.

Expected Behavior

Svelte Kit should be updated to 2.43.2 if latest is 2.43.4 and not older than 2 days.

[raineorshine]

Hi, thanks for reporting.

This behavior is expected and is a limitation of the npm registry. If the latest version is still under cooldown, we cannot upgrade to an earlier version, because there is no history of latest versions in the npm registry. Only the version currently published to the latest tag is known to be stable.

If --target newest or --target greatest is specified then it will upgrade to the next version not under cooldown, though you will not be tracking latest any more.

[k3nsei]

But with that it will never bump packages that are released frequently few times a week.

[raineorshine]

That's correct. Either we need a secure history of latest versions to be stored in the npm registry, or we need to adopt a heuristic that guesses what the last stable version is before the cooldown. Depending on the versioning scheme of the package, the latter could be quite effective.

[k3nsei]

There is command for listing all package versions

npm view @sveltejs/kit versions

and as JSON

npm view @sveltejs/kit versions --json

[oliverlockwood]

@raineorshine it seems to me that -t greatest works as documented with -c or --cooldown, but -t minor, -t patch, -t newest do not behave as expected.

Consider a module where I have a dependency on mocha, that is currently using version 11.7.0.
Right now, https://www.npmjs.com/package/mocha?activeTab=versions reports this:

My expectations are based on your documentation at https://github.com/raineorshine/npm-check-updates/releases/tag/v18.2.0, and the age of the components.

Command	Expected result.	Actual result
ncu -c 7 -t greatest mocha	Upgrade to 11.7.2	CORRECT - upgrades to 11.7.2
ncu -c 7 -t newest mocha	Upgrade to 11.7.2	WRONG - upgrades to 11.7.4
ncu -c 7 -t minor mocha	Upgrade to 11.7.2	WRONG - says "No package versions were returned"
ncu -c 7 -t patch mocha	Upgrade to 11.7.2	WRONG - says "No package versions were returned"

What seems to be happening, contradicting your documentation, is:

• the -c parameter is completely ignored when you set -t newest
• the -c parameter, regardless of the number (it behaves the same with -c 0 or -c 1) - breaks npm-check-updates when you set -t minor or -t patch.

If you'd prefer me to report this as a separate issue, I'd be happy to do so, but I thought it fit with the spirit of this existing issue.

This is a bit of a sticking point for us with what would otherwise be a fantastic new feature. Sometimes we want to force to only do minor or patch upgrades, for our own reasons, and currently this appears to be fundamentally incompatible with use of the new cooldown flag.

[raineorshine]

Hi @oliverlockwood. Thanks for bringing this to my attention! Definitely looks like a bug. If you could report this in a separate issue that would be great. I'd like to keep this issue as an FAQ for the expected non-upgrade behavior.

[SebastianSedzik]

@oliverlockwood, could you please confirm which version of ncu you’re using? Version 18.2.0 contained an issue where targets other than latest and greatest did not support the cooldown option. The fix was introduced in 18.3.0.

[oliverlockwood]

Thanks for this @SebastianSedzik, I was using 18.2.0; I'll retest now with 18.3.1 (based on https://github.com/raineorshine/npm-check-updates/tags) before raising the issue.

Why was I using 18.2.0? I had looked for versions on https://github.com/raineorshine/npm-check-updates/releases and decided I didn't want 19.0.0 yet, due to its breaking changes, and 18.3.0 is not listed here!

[oliverlockwood]

I can confirm that with 18.3.1 these targets work correctly.
Apologies for creating noise on this issue conversation.

@raineorshine It might be worth making the releases page include entries for all releases (even if some of them may be very terse)? But obviously I could have found the right version through NPM package listing or the tags page, so perhaps you could argue this is unnecessary. Anyway, I'll leave it to you to decide.

[raineorshine]

I can confirm that with 18.3.1 these targets work correctly.
Apologies for creating noise on this issue conversation.

No problem! Better safe than sorry.

@raineorshine It might be worth making the releases page include entries for all releases (even if some of them may be very terse)? But obviously I could have found the right version through NPM package listing or the tags page, so perhaps you could argue this is unnecessary. Anyway, I'll leave it to you to decide.

Good idea. added in 9af070e. Assuming I configured it correctly, it should from now on automatically publish a GitHub release for each tag.

[codyebberson]

Hi @raineorshine, first of all, thank you so much for maintaining this project! It’s an essential part of our workflow.

In case it wasn't obvious to others, you can actually achieve the behavior @k3nsei is looking for by using:

--target greatest --pre 0

Since --target greatest normally defaults to including pre-releases (--pre 1), adding --pre 0 forces ncu to only look at stable semver releases. It then scans the full version history to find the highest stable version that satisfies the cooldown requirement, rather than just checking the @latest tag.

Thank you again for all your efforts on this project! 🙏

[tlaurie-cl]

Hi @raineorshine, first of all, thank you so much for maintaining this project! It’s an essential part of our workflow.

In case it wasn't obvious to others, you can actually achieve the behavior @k3nsei is looking for by using:

--target greatest --pre 0

Since --target greatest normally defaults to including pre-releases (--pre 1), adding --pre 0 forces ncu to only look at stable semver releases. It then scans the full version history to find the highest stable version that satisfies the cooldown requirement, rather than just checking the @latest tag.

Thank you again for all your efforts on this project! 🙏

This solved my issue where --cooldown seemed to completely miss versions as described in this issue.

I don't understand why the default for --target is latest, it causes this unintuitive interaction with --cooldown.

I'd expect ncu --cooldown=10 to work like ncu --cooldown=10 --target=semver --pre=0 or ncu --cooldown=10 --target=greatest --pre=0 by default out-of-the-box.

[raineorshine]

The default target for npm-check-updates is always latest, just like npm install. This needs to be the default target even with cooldown, as I don't wish to conditionally change the target based on other options.

More importantly, ncu --cooldown=10 --target=greatest --pre=0 can potentially upgrade to versions that have never been published to the latest tag, which is not desirable for default behavior. --pre doesn't cover this unfortunately. It is valid semver for package authors to publish non-prerelease versions to other tags.

npm-check-updates takes a conservative approach when there is ambiguity. It would rather skip an upgrade than suggest an unstable version by default. Explicitly opting in to a different target affirms that the user understands the additional risk.

The core issue is that the npm registry does not expose the history of versions that have been published to latest, which would allow for more intuitive cooldown behavior.

Hope that helps clarify the current unintuitive but safe behavior.