Repository navigation
Feedback: --no-narrow should be the default #223
Description
The entire point of a lockfile is full 100% pinning. Thus, any further pinning offers zero benefit.
When I have @v2 in a workflow, I'm documenting my intention - to follow the v2 branch/tag. By narrowing, you're erasing the most important piece of information on that line - it's actively harmful.
Please change the default - with a lockfile present, ranges outside of that should be as WIDE as possible, not as narrow as possible.
Reacted by Jamie Tanna and ikedam
Activity
nodeselector commentedon Oct 21, 2026
Something we can add to #133 potentially but the narrowing pushes the workflow closer to having actual versions not mutable refs. This makes it easier to know if you are on v2.0.1 or v2.8.3 without an opaque commit and a comment annotation. I agree with you, though, that we lack a syntax to express what you desire, but I don't think mutable refs are the solution (something like npm semver would be more precise but requires a few changes on our side first and a few design decisions).
[-]`--no-narrow` should be the default[/-]ljharb commentedon Oct 21, 2026
The way to determine that is to look at the lockfile. The workflow (like a package.json) is supposed to indicate a range.
Tags aren't actually versions inherently, even though the rational choice is to treat them like semver - it's just a git commit-ish, and those are mutable by definition.
webknjaz commentedon Oct 25, 2026
xref for custom semver-major syntax: #238 (comment)