[Feature Request] Take minimumReleaseAge into account for nub outdated

[akhansari]

Currently, when running nub outdated, we get:

Package         Current  Wanted  Latest
@biomejs/biome  2.5.7    2.5.8   2.5.8

However, seeing the same output again right after running nub update is confusing when minimumReleaseAge is configured.

I think it would be better to either:

• Follow pnpm's approach: Hide updates that do not meet the minimumReleaseAge requirement.
• Display the age explicitly.

For example:

Package         Current  Wanted  Latest  Age
@biomejs/biome  2.5.7    2.5.8   2.5.8   8h

nub v0.7.5

[pullfrog]

Investigating. Confirmed in the code, and it is not a duplicate — no other open issue covers outdated and the age gate.

What happens today

nub outdated never consults minimumReleaseAge. collect_rows in vendor/aube/crates/aube/src/commands/outdated.rs computes Wanted as the highest packument version satisfying the manifest range and Latest straight from the latest dist-tag — no cutoff, no exclude list, no strict check anywhere in the file. nub update resolves through the gated resolver path instead, which since #682 falls back to the newest release that clears the cutoff. So the two commands answer different questions, and the report loops until the window expires.

Two things make this worse under Nub than under pnpm 10:

• minimumReleaseAge defaults to 1440 minutes (24h), so every user sees this on any dependency published in the last day, whether or not they configured anything.
• Nub pins minimumReleaseAgeStrict on, so there is no "install it anyway" path that would eventually make the row disappear on its own.

The report is also load-bearing for CI: outdated exits 1 on drift, and today it exits 1 for upgrades Nub would refuse to install.

Prior art

pnpm hides immature upgrades, as the issue says. It arrived as a bug fix (pnpm#11698 → pnpm#11705, which routed maturity through policyViolation for every caller including outdated), with a regression test in pnpm#11699.

Worth reading what came after it, because hiding alone has not settled well:

pnpm issue	State	Complaint
#12662	open	Wants the rows back with a column saying when they become installable, or an --all bypass
#12818	open	Wants a Released column — the same request as the second option here
#11543	open	Users read the shorter table as outdated being broken
#10120	open	minimumReleaseAgeExclude is not honored by outdated, so exempted packages get hidden too

So both halves of the request are right, and they are not alternatives: the columns need to agree with what nub install/update will do, and the held-back version needs to stay visible rather than vanish.

Shape a fix would take

Not committing to building this, but the pieces already exist:

1. Gate the pick. Add a gated sibling of wanted_version (commands/package_spec.rs) that calls the resolver's existing pick_version with the cutoff, honoring minimumReleaseAgeExclude and strict mode — the same machinery pick_version_for_add uses, so outdated and update cannot drift to two answers. Wanted becomes the mature pick; Latest stays the dist-tag.
2. Get the settings into the command. outdated's single-project path (run_one) builds no settings context today; run_filtered already does, and settings_context::build_resolver is the established seam for non-install verbs.
3. Publish times. This is the real cost. outdated fetches abbreviated packuments, which often carry no per-version time. The gate needs either the full packument (as add does when registrySupportsTimeField is false) or the document-level modified upper bound that already keeps corgi metadata usable. Note the comment in build_resolver about deliberately skipping the full-packument disk cache so latest is observed fresh — that tradeoff has to be made consciously here.
4. Disclose, don't hide. Keep the row and add the age, per the issue's second option. An Age/Released column on the version being held back reads better than a silently shorter table, and it sidesteps pnpm's complaint stream above. --long is the natural place if the default table should stay narrow.
5. Exit code and JSON. Once Wanted is gated, a project whose only drift is immature exits 0 — that is the correct answer for CI and a deliberate behavior change worth calling out in the release note. --json claims a pnpm-compatible shape, so any age field is additive.

A bypass is cheap to offer alongside: --minimum-release-age already exists from #645 but rides the install-family args, so the read-only verbs (outdated, audit, list) do not parse it. Wiring it there gives the escape hatch pnpm users are asking for in pnpm#12662.

One adjacent gap found while reading: nub update -i's picker rows use the same ungated wanted_version (commands/update.rs:1192 and :1344), so the picker can offer a target the resolver then declines. Same root cause, same fix.

  ^{｜ View workflow run ｜ via Pullfrog ｜ Using Claude Opus ｜ 𝕏}