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
What
plugins.lua:10 marks fff.nvim with:
version = vim.version.range("0.9.4"),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:10
Why it matters
If vim.pack enforces 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:
version = vim.version.range(">= 0.9.4, < 0.10"),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 the version field at all, since it is a nightly/experimental API. If it is ignored, the lazy = true field on the same entry may also be silently ignored (fff.nvim would then load at startup rather than on demand).
Activity
stanfish06 commentedon Sep 28, 2026
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:A 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: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