Have you thought about integrating some or all of these into go release? #26420

The upside is that we wouldn't need a separate command or service for this, and we'd have a single command to ensure that all modules conform to a certain standard.

The downside is that users need to trust that authors are using the command when doing each release. Perhaps we could let users run the checks themselves too, e.g. go release -check some/module.

@mvdan

Have you thought about integrating some or all of these into go release? #26420

Yes that did indeed cross my mind (but I failed to reference #26420). Rightly or wrongly I thought I'd start discussion about the "health check" separately. But we can/should fold this issue into #26420 in case that's more appropriate.

I agree discussion should start separately to begin with. There's some overlap with that issue, but they're certainly not duplicates.

Haven't thought about the features, but go mod vet seems like the obvious name. 🙂

Haven't thought about the features, but go mod vet seems like the obvious name. 🙂

Assuming the mod command isn't going anywhere, sounds good!

Much like we have golint separate from go vet, it might also make sense to have a repository linter:

• someone coming from a more Java background might be tempted to put everything under src
• suggest putting commands in cmd/
• ...

These tests would surely be very fuzzy... but might be good enough.

Definitely a separate tool.

Just noting the idea here for now.

@myitcv has mentioned multiple times that a tool such as he describes above could be built outside of the core go tool to start.

FYI, this weekend, I put together a very rough cut of something in this ballpark: https://github.com/thepudds/gomodvet

It is very much WIP / prototype level, but wanted to at least mention it. In particular, this first cut was helpful this past weekend to concretely illustrate to some people that some sanity checking is possible to at least increase the odds of catching someone accidentally stepping on some potential modules-related landmines.

gomodvet currently has 8 notable things it finds (that is, 8 "rules"):

• gomodvet-001: the current module's go.mod file would be updated by 'go build'
• gomodvet-002: a module has multiple major versions in this build
• gomodvet-003: module "foo" was required with potential incompatible versions: v0.9.0, v1.0.0
• gomodvet-004: using a version excluded by another module: github.com/go-chi/chi@v1.0.1
• gomodvet-005: using a prerelease version: github.com/go-chi/chi@v4.0.0-rc2
• gomodvet-006: using a pseudoversion version: github.com/go-chi/chi@v0.0.0-20151106203253-e413833c12f1
• gomodvet-007: dependencies have available updates
• gomodvet-008: the current module uses 'replace' directives

Most of those are not strictly speaking "problems" in all cases, but most of those are at least notable situations. (E.g., a module with multiple major versions in a build might be a conscious choice, or might be because someone is doing import "foo/v3" in one spot and accidentally doing import "foo" in another spot).

You can control what you do / don't want to be told about via a command line flag for each rule.

The current gomodvet might have more overlap with #26420 than some of the specific modanalyse ideas outlined in the discussion above, but wanted to post here first, including because this issue here is a bit more low-key and has more brainstorm-style discussion.

The intent of gomodvet is mainly experimentation -- ideally anything useful in gomodvet would land in an ultimate go release or go mod vet (or otherwise somewhere in the go tool).

edit: the public gomodvet repo was slightly behind when this comment was first posted, but now it has the latest version with 8 rules.

This would be really useful, there are module maintainers out there who publish unusable, or difficult to use modules at the moment. Currently, they sometimes refuse to fix the problems even when pointed out, because they are not affecting that team's ability to write code, just other teams' ability to consume it. If there were an official go tool that could call out this kind of problem, then it could provide a concrete bug to report to maintainers which might help the ecosystem become more usable. Even better if it detected breaking API changes and suggested using the vN+1-beta pattern so maintainers knew there was a way out and they did have the option to make breaking/experimental changes without damaging the ecosystem.