Repository navigation
[audit] vim.version.range("0.9.4") creates an open range ≥0.9.4, not a pin to exactly 0.9.4 #261
Description
Activity
Premise disproven — recommend closing
This issue's core claim (
vim.version.range("0.9.4")produces an open>= 0.9.4range) does not hold, confirmed two independent ways:-
PR [audit] fix: bound blink.cmp version range to stay off v2 #328 (2026-09-21) tested the equivalent
blink.cmpcase directly against nvim 0.13.0-dev-1661:vim.version.range("1.10.0") from=1.10.0 to=1.10.0 has("2.0.0") = falseA single-arg spec with all three version components (major.minor.patch) is an exact pin, not an open range —
vim.version.rangehas no comma-compound parser, so>= 0.9.4alone would actually behave differently (open), but a bare three-component string like"0.9.4"pins exactly. -
nvim-pack-lock.jsonindependently confirms this at the data level — both affected entries record the resolved range as an exact match, not an open one:"fff.nvim": { "version": "0.9.4 - 0.9.4" } "blink.cmp": { "version": "1.10.0 - 1.10.0" }If the range were truly open-ended (
>= 0.9.4), the lockfile would show no upper bound — it doesn't.
So
plugins.lua:16'sversion = vim.version.range("0.9.4")already does what the adjacent comment says it does (pin exactly, to guard against the "breaks frequently" plugin). The secondary question this issue raised — whethervim.pack.add()enforcesversionat all — is also answered by the same lockfile evidence: it does, and used it to pick exactly0.9.4.Recommend closing as invalid. (Noting this now because a plugin-version sweep this cycle found
fff.nvimupstream has since moved to v0.11.0 — see the update on #271 — and any future decision to bump the pin should account for it being a real exact-pin today, not an already-open range.)
Generated by Claude Code
-
What
plugins.lua:10marks fff.nvim with:The comment on the same line says "this package breaks frequently, specify version", implying the intent is to pin fff.nvim at exactly 0.9.4. But
vim.version.range("0.9.4")produces a range constraint meaning >= 0.9.4 with no upper bound — any later release also satisfies it.Where
lua/config/plugins.lua:10Why it matters
If
vim.packenforces version ranges during updates (behaviour may vary by nightly build), fff.nvim could be updated to a breaking release while the user believes it is pinned. The comment intent and the actual constraint are mismatched.Recommended action
To constrain to the 0.9.x line only, use an explicit upper bound:
To pin to a single exact release, use a git SHA instead of a version range (vim.pack accepts a
pin/ commit-hash field depending on nightly API). Alternatively, accept that the constraint is a lower-bound floor and update the comment to reflect that.Also worth verifying: whether
vim.pack.add()actually reads and enforces theversionfield at all, since it is a nightly/experimental API. If it is ignored, thelazy = truefield on the same entry may also be silently ignored (fff.nvim would then load at startup rather than on demand).