DECISION: golangci-lint warns gomodguard is deprecated, but .golangci.yml must stay canonical #29

New Issue

clawbot · 2026-08-09T10:13:36+02:00

clawbot commented

2026-08-09 10:13:36 +02:00

Problem

Every make lint run now emits:

The linter 'gomodguard' is deprecated (since v2.12.0) due to: new major version. Replaced by gomodguard_v2.
Suggested new configuration:
linters:
  enable:
    - gomodguard_v2

It does not affect the result — main is still 0 issues — but it is noise on
every run, and deprecations are action items rather than background hum.

Nobody can fix it in this repo. .golangci.yml here is byte-identical to
the org canonical config (sha256
021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb), and
MEMORY.md forbids editing it without your explicit permission. Changing it
locally would break the very property that makes it verifiable.

Three separate agents have now flagged this and all three correctly declined
to act. Filing it so it stops recurring as an advisory on every PR.

Why it is your call

The fix belongs upstream in the canonical config, not here. Two things
need deciding:

Whether to migrate gomodguard → gomodguard_v2 in the shared config at
all, and when.
Whether rgoue tracks the canonical config's new hash immediately once it
changes, or lags.

Both affect every repo that vendors this config, so neither is a per-repo
decision.

Options

A. Migrate upstream, then re-sync here. Swap the linter in the canonical
.golangci.yml, re-hash, and update every repo that vendors it (here it is a
one-line linters.enable change plus a new expected sha256). Correct and
durable. Costs a coordinated sweep across repos.

B. Do nothing for now. The warning is harmless and gomodguard still
works. Revisit when golangci-lint actually removes it — at which point it
becomes a hard failure rather than a warning, on every repo simultaneously,
possibly at an inconvenient moment.

C. Suppress locally. Rejected, and listed only to be explicit: it would
require editing .golangci.yml, breaking byte-identity with canonical. Do not
do this.

Recommendation

Option A, but not urgently. The migration is a one-line change per repo;
the risk is that a future golangci-lint release removes gomodguard outright
and turns a warning into a red gate everywhere at once, with no warning window
left to plan in. Doing it deliberately now is cheaper than doing it under
pressure later.

Note this is entangled with #4: if you adopt a hash-pinned linter there, the
deprecation stops being a moving target, because the version that produces the
warning becomes a fixed, known quantity rather than whatever the host happens
to have. Worth deciding #4 first.

Definition of done

Not actionable in this repo until you rule. Once the canonical config changes:
make lint runs with no deprecation warning, still reports 0 issues, and
.golangci.yml still matches the canonical file's new hash exactly.

Assigning to you. Not blocking — everything else continues.

## Problem Every `make lint` run now emits: ``` The linter 'gomodguard' is deprecated (since v2.12.0) due to: new major version. Replaced by gomodguard_v2. Suggested new configuration: linters: enable: - gomodguard_v2 ``` It does not affect the result — `main` is still 0 issues — but it is noise on every run, and deprecations are action items rather than background hum. **Nobody can fix it in this repo.** `.golangci.yml` here is byte-identical to the org canonical config (sha256 `021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb`), and `MEMORY.md` forbids editing it without your explicit permission. Changing it locally would break the very property that makes it verifiable. Three separate agents have now flagged this and all three correctly declined to act. Filing it so it stops recurring as an advisory on every PR. ## Why it is your call The fix belongs **upstream in the canonical config**, not here. Two things need deciding: 1. Whether to migrate `gomodguard` → `gomodguard_v2` in the shared config at all, and when. 2. Whether rgoue tracks the canonical config's new hash immediately once it changes, or lags. Both affect every repo that vendors this config, so neither is a per-repo decision. ## Options **A. Migrate upstream, then re-sync here.** Swap the linter in the canonical `.golangci.yml`, re-hash, and update every repo that vendors it (here it is a one-line `linters.enable` change plus a new expected sha256). Correct and durable. Costs a coordinated sweep across repos. **B. Do nothing for now.** The warning is harmless and `gomodguard` still works. Revisit when golangci-lint actually removes it — at which point it becomes a hard failure rather than a warning, on every repo simultaneously, possibly at an inconvenient moment. **C. Suppress locally.** Rejected, and listed only to be explicit: it would require editing `.golangci.yml`, breaking byte-identity with canonical. Do not do this. ## Recommendation **Option A, but not urgently.** The migration is a one-line change per repo; the risk is that a future golangci-lint release removes `gomodguard` outright and turns a warning into a red gate everywhere at once, with no warning window left to plan in. Doing it deliberately now is cheaper than doing it under pressure later. Note this is entangled with #4: if you adopt a hash-pinned linter there, the deprecation stops being a moving target, because the version that produces the warning becomes a fixed, known quantity rather than whatever the host happens to have. Worth deciding #4 first. ## Definition of done Not actionable in this repo until you rule. Once the canonical config changes: `make lint` runs with no deprecation warning, still reports 0 issues, and `.golangci.yml` still matches the canonical file's new hash exactly. Assigning to you. Not blocking — everything else continues.

sneak was assigned by clawbot

2026-08-09 10:13:36 +02:00