gomodguard deprecation warning on every lint run — needs a fix in the canonical config #26
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Since #3 landed, every
make lintrun emits a deprecation warning forgomodguard. Standing practice is that deprecation warnings are action items rather than noise, so this is filed rather than ignored.It cannot be fixed in this repo. The warning originates in
.golangci.yml, and REPO_POLICIES is unambiguous: ".golangci.ymlis standardized and must NEVER be modified by an agent, only manually by the user." This repo's copy is already byte-identical to the canonical file (sha256021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb), so any local change would both violate that rule and immediately drift from the org standard.Assigning to you, since the fix belongs in the
promptsrepo and the choice is yours.Options
A. Update the canonical
.golangci.ymlinpromptsto whatever golangci-lint v2.12.2 wants instead of the deprecatedgomodguardconfiguration, then re-vendor the new file into every repo that carries it. Fixes it everywhere, once. Cost: one pass over all repos holding a copy, and each needs a re-lint in case the replacement behaves differently.B. Leave it. It is a warning, not a failure;
make lintstill reports0 issues.and CI is green. Cost: every lint run in every Go repo prints it, and it will keep printing until the linter eventually removes the option outright — at which point it becomes a hard failure at an unpredictable time.Recommendation: A. The warning is upstream's advance notice that this configuration is going away. Doing it deliberately now, across all repos at once, is cheaper than discovering it as a broken build on whichever repo happens to bump the linter first. It is also a one-line class of change, not a redesign.
If you take A, this issue closes by re-vendoring the updated canonical file here and confirming the sha256 matches the new upstream. If you take B, close it as wontfix and it will resurface on the next linter bump.
Definition of done
promptsis updated, re-vendored into this repo, the new sha256 is recorded in the PR, andmake lintruns clean with no deprecation output.Independently rediscovered while implementing #24 (filed as #35, now closed as a duplicate of this issue).
One thing that changes the urgency slightly, in your favour if you were leaning toward leaving it. Before #24, this warning only appeared inside the Docker lint stage, because most developer hosts were silently running whatever older golangci-lint they happened to have — this one had v2.10.1 against a v2.12.2 pin. Once #24 lands, every host actually runs v2.12.2, so the deprecation warning shows up on every local
make lintandmake checktoo, for everyone, in every Go repo carrying the canonical config.That makes option B (leave it) noisier than it looked when I first wrote this issue: it is no longer one warning in CI logs, it is a warning on every developer's every check run. Recommendation stays A — update the canonical file upstream and re-vendor.
Still yours to decide; nothing here is blocked on it.