dep-check 0.9.0: a range ahead of the registry is not a range behind it - #25
Merged
Conversation
A declared range can miss `latest` from either side, and check C described
both as behind. They are opposite problems: behind means the range stopped
at an older major; ahead means its floor is above everything published, so
the package installs nowhere.
The second read:
[contract] @theokit/sat @theokit/sdk >=99.0.0 latest 4.59.0 (0 majors behind)
`0 majors behind`, for a package no consumer can install. The measurement
was right and the label described its mirror image.
It comes up for a real reason. A two-release change has the satellite
declare the floor it will need before the sibling that provides it has
published — theokit-sdk is about to be in exactly that state for
@theokit/sdk-memory. That is legitimate and temporary, and in the old output
it was indistinguishable from a range wrong for a year, which is the whole
question a reader has.
`ahead` now has its own severity, sorts above `contract` — a range the
registry cannot satisfy at all is worse than a stale one — and carries no
majors-behind count, since the number was the misleading part. The legend
says when the state is expected, not only what it is.
Check C still never blocks. Two-release ordering is a property of publishing
interdependent packages, not something a gate should refuse; the gate's job
is to name which state you are looking at.
Refs #24
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Releases
@theokit/dep-check@0.9.0. Fixes #24.A range ahead of the registry was labelled as behind it
Both miss
latest; they are opposite problems.The second was reported as:
0 majors behind, for a package no consumer can install.Why it matters now
It is the expected state mid-way through a two-release change — a satellite declaring the floor it will need before the sibling that provides it publishes.
usetheokit/theokit-sdkis about to be in exactly that state:@theokit/sdk-memoryneeds a shared sub-path shipping in a later@theokit/sdk, so the floor cannot be declared and satisfied in one release.Legitimate and temporary — and, in the old output, indistinguishable from a range that has been wrong for a year. That difference is the entire question a reader has.
After
unpublishedsorts abovecontract, and the legend says when the state is expected rather than only what it is. Anaheadfinding carries no majors-behind count — the number was the misleading part.Verified in both directions: zero findings against
theokit-sdk, one correctly labelled against a fixture declaring>=99.0.0.Unchanged
Check C still never blocks. Two-release ordering is a property of publishing interdependent packages, not something a gate should refuse.
84 tests, four new — including the one that names the defect: an
aheadfinding must not report a majors-behind count.