Documentation
¶
Overview ¶
Command modcheck gates the nested modules on being resolvable the way a consumer resolves them: from their own go.mod, with no workspace.
go.work makes every module in the repository resolve the core module from the checkout, so a nested go.mod can require a core version that predates a package its own code imports and nothing here notices. The module then builds for everyone working in this repository and for nobody fetching it from the proxy. drivers/postgres shipped exactly that: it required core v0.20.0 while its integration tests imported vukem/flags, added in v0.27.0.
For each drivers/* and contrib/* module, modcheck runs "go vet" in the module directory with GOWORK=off, so the module's own requirements are the only thing that can satisfy its imports. Test files count: the postgres defect was in one, and a build-tagged one at that, which is why the vet runs with every custom build tag the module's own files declare. Without -tags integration the defect is invisible even with GOWORK=off.
It also fails when a module is missing from go.work, because a module outside the workspace is not built by anything run from the root.
Run from anywhere inside the repository:
go run ./internal/tools/modcheck