document "reserved standard library" module paths

[twmb]

If I have the following directory structure:

go.mod
main.go
pkg/thing/thing.go

with the following file contents:

go.mod:

module foo

go 1.16

main.go:

package main

import (
	"fmt"

	"foo/pkg/thing"
)

func main() {
	fmt.Println("hello")
	thing.Print()
}

pkg/thing/thing.go:

package thing

func Print() {
	println("foo")
}

Then gofumpt will change main.go's import block such that the foo/pkg/thing import is tied to the stdlib fmt import.

I think this is only possible to detect with the current gofumpt implementation if gofumpt reads the go.mod file to know what module it is in. If import == module || strings.HasPrefix(import, module + "/"), then the import is non-standard. I do not see a way to have this same logic if just relying on the ast. Another potential option is to just have a list of stdlib imports, but this obviously is not future proof for when the stdlib adds new modules (a user would have to update gofumpt, which also would then have the obligation of staying up to date with Go releases).

[mvdan]

You seem to understand what's going on here :) Have you seen #117 (comment)? I might add that to a FAQ since this keeps coming up.

[mvdan]

I think this is only possible to detect with the current gofumpt implementation if gofumpt reads the go.mod file to know what module it is in.

That's planned for #38, so that would affect grouping imports too. Still, though, you shouldn't be using paths which are "reserved for std" as per the explanation above.

[mvdan]

friendly ping :) did you see my reply above?

[twmb]

Yep -- I updated the module in question to be a github based name, not a single word. given #38 and your golang issue, I'm thinking the only thing to do here would be to update the FAQ.

[mvdan]

Thank you - agreed.

[mvdan]

I'll leave this open as a doc reminder for myself, if that's OK :)

[mvdan]

FYI, see #187 (comment); I'm currently thinking we could do better for everyone by looking at the main module's path.