The problem is that before you can run go mod tidy on the legacy project you have to add the module name to the import statements. That needs to be included in that blog post. Also the project used in the blog post has already been converted to modules so it doesn't illustrate anything.

@stevetraut is working on new tutorial content for modules.

(We should take this feedback into account in the tutorials.)

I think the first place folks will look for information about what the command requires to run usefully is in the reference for go mod tidy. This behavior should be reflect in other module docs, but I don't think people will look there first because it's less immediate.

In this case, I think what we're missing is probably a tutorial on “converting a GOPATH project to use modules” when the existing GOPATH contains packages that are intended to go in different modules.

(Our existing blog post assumes that the whole GOPATH project is a single module, so it doesn't describe how to use replace directives to wire in other dependencies from outside of that module that can't — or can't yet — be fetched using go get.)

Can we set aside the content delivery vehicle for a moment and focus on what users need to be successful? What bits of information does a user need to have in order to successfully migrate GOPATH code to modules?

In this particular case, the user needs to know that they should add replace directives in the go.mod file for their new module for for any existing dependencies that cannot be fetched using go get.

At this point I'm not sure that it's worth adding a lot of new documentation on converting legacy projects, as a significant fraction of projects have already been converted to modules.