Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: error out of more commands used by module authors if go.mod's Go version is newer #50468

mvdan opened this issue Jan 6, 2022 · 2 comments


Copy link

@mvdan mvdan commented Jan 6, 2022

#46142 is a great change. It would have saved some head scratching for a coworker of mine, who was running go mod tidy on 1.16.x on a module that declared go 1.17. This version mismatch was causing problems, such as unintentionally removing some require lines.

I reckon we should throw this error for any command that relates to authoring a module and not just using it. Of course, only when run inside a module that has such a version mismatch. Off the top of my head:

  • go get, as nowadays it's only used for changing the module requirements.
  • go work, given how similar it is to go mod. Perhaps it should compare with the go 1.N line in the file?
  • go fix and go generate, as they can only be useful to an author, given how they modify source files
  • Any other go mod command, not just go mod tidy. For instance, go mod edit or go mod vendor both feel potentially broken on a version of Go that's too old.
Copy link
Member Author

@mvdan mvdan commented Jan 6, 2022

One may argue that there's no harm in some of these, like go fix or go generate, but I also think we should consistently push authors towards using a Go version that's recent enough to be compatible with authoring a module.

Copy link

@bcmills bcmills commented Jan 6, 2022

I think go generate and go fix are probably ok — if the generator program runs successfully on the older version it should produce the same output, and go fix on a newer version shouldn't actively undo transformations applied by go fix on an older version (or vice-versa).

But I agree that go get and go work should probably error out if they don't know how to interpret the main module's (or the workfile's) go version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants