go work tidy

[Nicholas Corran]

I'm interested if anyone has considered/dismissed/is working on the concept of go work tidy.

In a large project (mono github repo) which has a go.work file at the root, and includes multiple go.mod files for different projects (e.g. reflecting different owner teams, deliverables, tests etc) there is a challenge when it comes to updating the base Go version and the Go package versions.

In a single go.mod setup we would use go.tidy to help.

In a go.work setup (specifically where we are building all the Go code into one final 'product/image') we want to make sure we have consistent versions of the Go packages across all the go.mod files.

Currently there is a manual step of:

Go to each go.mod file, go tidy it, move the package version information into go.work, run go work sync to push the updates out to all the go.mod files...

... and iterate across each go.mod file

... and then iterate again because changes made later can re-impact go.mods earlier in the cycle where they share a package.

This whole workflow is ripe for help/automation and it seems that go work tidy would be the 'right way' to do this.

Any comments for/against?

Is this worth becoming a Proposal?

Is there someone more familiar with go work development could comment on whether this makes sense?

[Michael Matloob]

Hi,

If I understand your use case, I think it should be covered by go work sync, but it seems like there is a bug in the behavior of "go work sync". If the changes being made by go work sync aren't stable, so that a run of go work sync following a previous run produces different go.mod files, something isn't working correctly. Could you file a bug with a reproducible workflow? Alternatively I'd be available for a video call to talk about this if that's easier.

Thanks,

Michael