March 11, 2026

Go linting with nogo in Bazel

i use nogo instead of golangci-lint for Go linting in Bazel. nogo is a rules_go feature that compiles Go analyzers into the build. Lint errors become build errors. Bazel caches results per package, so incremental builds only re-lint what changed. golangci-lint has its own cache, but it doesn’t share between CI and local, so you duplicate work. Setup You enable nogo in MODULE.bazel by pointing go_sdk.nogo at a nogo() target: go_sdk = use_extension("@rules_go//go:extensions.bzl", "go_sdk") go_sdk.from_file(go_mod = "//:go.mod") go_sdk.nogo(nogo = "//:nogo") go_sdk.from_file reads the Go version from your go.mod, so you don’t duplicate it. You can also use go_sdk.download(version = "1.24.5") if you want to pin it explicitly. Read more

December 8, 2024

Replace Buf Remote Plugins with local vendored plugins

Buf is the best tool to manage protobufs. One of the biggest pain points of protobuf is the management of protoc plugins. You need to manage them, and make them available to other engineers working on the same repository/project. Versions need to be centrally managed, code generation must produce the same result, no matter if it happens on an engineer A or B’s machine, or in CI. This becomes even more challenging, as protoc plugins are written in different programming languages. Go protoc plugins are written in Go, and are therefore compiling to a single binary without dependencies. Easy. However, other plugins are more difficult to manage. Typescript plugins like protoc-gen-es are written in Typescript, and therefore do not compile to a single binary. Read more