#468 react-scan 0.5.x floats react-grab and react-doctor on the "latest" dist-tag, making resolutions non-reproducible

Description

[email protected] declares two of its dependencies with the latest dist-tag rather than a semver range:

// [email protected]
"dependencies": {
  "react-doctor": "latest",
  "react-grab": "latest"
}

react-grab has been latest since 0.5.5, and react-doctor was added the same way in 0.5.7.

Because latest is a moving target, the resolved transitive tree depends on the day you install rather than on the version of react-scan you asked for. [email protected] installed in May and [email protected] installed today are different dependency graphs.

Why this matters

Reproducibility. A lockfile protects a project that already has one, but it does not help a fresh npm i react-scan, a lockfile regeneration, a bot-driven re-resolution, or anyone reproducing a bug report. #467 illustrates this: the reporter's environment lists react-grab: 0.1.37, while latest today is 0.1.50. Two people following identical steps get different trees, which makes triage harder than it needs to be.

Release cadence makes the window wide. react-grab has 146 stable releases (269 including prereleases), 18 of them in the last 90 days, with the most recent on 2026-07-23. react-doctor has 624 published versions, most recent 2026-07-25. These are not dormant packages where a floating tag would be harmless.

Supply chain gating. pnpm 11 enforces a minimumReleaseAge policy by default, holding back packages published within the last 24 hours. A dependency floating on latest is exactly the pattern that policy exists to catch, since a routine install can pull code published minutes earlier with no review and no changelog the consumer ever sees. Teams running that gate, or an equivalent policy, hit friction on react-scan that they do not hit on its peers.

There is already an implied compatibility contract. react-scan warns at runtime when the resolved react-grab is behind, as reported in #461:

[React Scan] react-grab v0.1.32 is outdated (latest: v0.1.44).
Update react-scan to pick up the newer react-grab

So a version relationship between the two packages is being asserted, it just is not expressed anywhere npm can act on. That check is also the code path that produces the REACT_GRAB_VERSION import in #467 and #447.

Suggested fix

Declare normal ranges and let the existing runtime check handle the "a newer one is out" nudge:

"dependencies": {
  "react-doctor": "^0.9.1",
  "react-grab": "^0.1.50"
}

Consumers still pick up compatible updates automatically, the resolution becomes a function of the react-scan version alone, and each bump becomes visible in a changelog and a diff. If the two packages really must move in lockstep, exact pins bumped by release tooling would express that more honestly than latest.

Environment

Encountered while triaging a dependency bump on a public Next.js app (disscount.me, source at https://github.com/OffCrazyFreak/Disscount).

react-scan: 0.5.7
next: 16.2.11
node: 22.19.0
pnpm: 11.9.0

This is separate from #467 and #447, which are about the JSON named import specifically. Fixing those does not change the floating-tag behaviour, and fixing this does not fix those.