golangci-lint warns on every run: gomodguard is deprecated, replaced by gomodguard_v2 #100

New Issue

clawbot · 2026-08-09T12:12:16+02:00

clawbot commented

2026-08-09 12:12:16 +02:00

Noticed while verifying PR #98; not fixed there because .golangci.yml
was out of scope for that change.

Every make lint run, host and containerised, emits:

level=warning msg="The linter 'gomodguard' is deprecated (since v2.12.0) due to: new major version. Replaced by gomodguard_v2."
level=warning msg="Suggested new configuration:\nlinters:\n  enable:\n    - gomodguard_v2\n"

This arrived with the golangci-lint v2.12.2 rollout (#61). The linter
still runs and lint is green — this is warning noise, not a failure.

It is worth clearing rather than living with: a check whose output
always contains warnings trains readers to skim past output that is
supposed to be read, which is the same habit that let the other
false-green mechanisms in this repo go unnoticed.

Definition of done

.golangci.yml enables gomodguard_v2 in place of gomodguard,
carrying across any existing configuration block for it (check
whether the v2 linter's config schema differs before assuming a
rename is enough).
make lint emits no deprecation warnings and stays at 0 issues.
Verify the linter is actually still doing its job after the swap, not
silently disabled by a config key the new version ignores.
script/cibuild exits 0.

Noticed while verifying PR #98; not fixed there because `.golangci.yml` was out of scope for that change. Every `make lint` run, host and containerised, emits: ``` level=warning msg="The linter 'gomodguard' is deprecated (since v2.12.0) due to: new major version. Replaced by gomodguard_v2." level=warning msg="Suggested new configuration:\nlinters:\n enable:\n - gomodguard_v2\n" ``` This arrived with the golangci-lint v2.12.2 rollout (#61). The linter still runs and lint is green — this is warning noise, not a failure. It is worth clearing rather than living with: a check whose output always contains warnings trains readers to skim past output that is supposed to be read, which is the same habit that let the other false-green mechanisms in this repo go unnoticed. ## Definition of done 1. `.golangci.yml` enables `gomodguard_v2` in place of `gomodguard`, carrying across any existing configuration block for it (check whether the v2 linter's config schema differs before assuming a rename is enough). 2. `make lint` emits no deprecation warnings and stays at 0 issues. 3. Verify the linter is actually still doing its job after the swap, not silently disabled by a config key the new version ignores. 4. `script/cibuild` exits 0.

clawbot commented

2026-08-09 12:13:26 +02:00

Closing as a duplicate of #90, which was filed earlier for the same
warning and is already assigned to sneak.

The reasoning here is good and I want it carried across rather than lost —
particularly the point that a check whose output always contains warnings
trains readers to skim output that is meant to be read. In a repo where
six distinct false-green mechanisms have now been found, warning noise is
not cosmetic; it is the habit that lets the next one through. I have
nothing to add to that framing.

One thing to correct, because it affects who can act: the definition of
done here starts with ".golangci.yml enables gomodguard_v2". That
file cannot be edited in vaultik. It is the org-standard config,
byte-identical across every Go repo in the org, currently sha256
021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb.
Changing it here would break the byte-identical invariant #59 established,
and invalidate the hash that #78, #85, #88, #91 and every recent PR assert
as their untouched-file check — assertions that exist precisely to prove
nothing was weakened to make lint pass.

The fix belongs upstream in sneak/prompts, then re-vendored to all
consuming repos with a coordinated hash update. Sibling repos track the
same warning (sneak/pixa#57, sneak/homoicon#4), confirming it is
org-wide. That is why #90 sits with sneak and is off the 1.0.0
milestone — it is not a vaultik work unit and cannot be closed by vaultik
work.

Also worth preserving from this issue: DoD item 3, "verify the linter is
actually still doing its job after the swap, not silently disabled by a
config key the new version ignores." That is the real risk in the
migration and it is the same failure shape as #78 and #85 — enforcement
quietly disappearing while the gate keeps reporting green. I have noted it
on #90.

Closing as a duplicate of **#90**, which was filed earlier for the same warning and is already assigned to `sneak`. The reasoning here is good and I want it carried across rather than lost — particularly the point that a check whose output always contains warnings trains readers to skim output that is meant to be read. In a repo where six distinct false-green mechanisms have now been found, warning noise is not cosmetic; it is the habit that lets the next one through. I have nothing to add to that framing. One thing to correct, because it affects who can act: the definition of done here starts with "`.golangci.yml` enables `gomodguard_v2`". **That file cannot be edited in vaultik.** It is the org-standard config, byte-identical across every Go repo in the org, currently sha256 `021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb`. Changing it here would break the byte-identical invariant #59 established, and invalidate the hash that #78, #85, #88, #91 and every recent PR assert as their untouched-file check — assertions that exist precisely to prove nothing was weakened to make lint pass. The fix belongs upstream in `sneak/prompts`, then re-vendored to all consuming repos with a coordinated hash update. Sibling repos track the same warning (`sneak/pixa#57`, `sneak/homoicon#4`), confirming it is org-wide. That is why #90 sits with `sneak` and is off the `1.0.0` milestone — it is not a vaultik work unit and cannot be closed by vaultik work. Also worth preserving from this issue: DoD item 3, "verify the linter is actually still doing its job after the swap, not silently disabled by a config key the new version ignores." That is the real risk in the migration and it is the same failure shape as #78 and #85 — enforcement quietly disappearing while the gate keeps reporting green. I have noted it on #90.

clawbot closed this issue

2026-08-09 12:13:33 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/vaultik#100