With the previous order, `go mod vendor` populated vendor/ from the
current go.mod, and only then did `go mod tidy` prune it. If tidy
changed go.mod, vendor/ was left matching the pre-tidy state, so a
single run could leave vendor/modules.txt inconsistent with go.mod
(it took a second run to converge). Tidying first settles
go.mod/go.sum, then vendor rebuilds vendor/ to match in one pass.
This applies both to the `vendor` recipe (justfile and Makefile)
and to scripts/bump_lazycore.sh.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
golangci-lint bundles gofumpt v0.8.0, which formats code differently
from the v0.9.2 we pin in go.mod. Enforcing formatting through
golangci-lint may therefore disagree with `just format`.
Remove gofumpt from golangci-lint's formatters and instead run the
pinned `go tool gofumpt` as a standalone check via a new
scripts/gofumpt-check.sh, wired into CI, `just lint`, and `make lint`.
goimports stays in golangci-lint; it's stable across versions and
nothing runs a competing copy of it.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
When a new enough gofumpt version is used (v0.9.0 or later), it suports the
`ignore` directive that we just added, so the workaround is no longer needed.
Co-authored-by: Stefan Haller <stefan@haller-berlin.de>
Instead of requiring the user to install the right version of the tool in their
.bin folder, create a shim that automatically runs the right version of the
tool. This has several benefits:
- it works out of the box with no setup required (the tool will be automatically
downloaded and compiled the first time it is used)
- no work needed for developers when we bump the golangci-lint version
- it works in working copies that are used in different environments (e.g.
locally on a Mac, or inside a dev container)
Co-authored-by: kyu08 <49891479+kyu08@users.noreply.github.com>
This has several benefits:
- it's less code
- we're using the same mechanism to generate all our auto-generated files, so if
someone wants to add a new one, it's clear which pattern to follow
- we can re-generate all generated files with a single command
("go generate ./...", or "make generate")
- we only need a single check on CI to check that all files are up to date (see
previous commit)
As far as I can tell, there's not much of a difference in behavior between the
two. The advantage of doing it this way is that you can attach a debugger to the
running lazygit process; see next commit.
Stefan HallerandClaude Opus 4.8
kyu08andStefan Haller