Go: x/tools/cmd/goimports: adds redundant aliases

[speedyhoon]

What version of Go are you using?

go1.11.1 windows/amd64 (Windows 10)

Does this issue reproduce with the latest release?

Yes

What did you do?

run goimports in the current directory.
goimports .

What did you expect to see?

package main

import "github.com/speedyhoon/v8"

func main() {
        v8.Str(nil, "")
}

What did you see instead?

package main

import v8 "github.com/speedyhoon/v8"

func main() {
        v8.Str(nil, "")
}

I named this package "v8", abbreviated from "validation". _(okay the name might be a little short)_
The package name seems to be colliding with assumptions around goimports matching a versioning pattern like: ^v[0-9]+$
However the alias in this case is redundant because it matches the package name exactly.

[mvdan]

/cc @heschik @matloob @rogpeppe @myitcv

[myitcv]

@speedyhoon - aside from any potential bug with goimports, you're going to need to use a different package name here:

https://github.com/golang/go/issues/28435#issuecomment-440324231

Because github.com/speedyhoon/v8 is also the module path as well as the path to the package named v8.

[heschik]

This is working as intended. goimports is recording the fact that this is a package named v8, rather than version 8 of the module github.com/speedyhoon. That allows it to avoid reading the package from disk in most cases, speeding up the common case where no dependencies are missing. I don't think there's a way to fix this without sacrificing performance in the much more common case that /vN is a version suffix.

[misterikkit]

That allows it to avoid reading the package from disk in most cases,

Sorry to jump in on a closed issue, but how/why does this improve performance? We have a ton of packages in kubernetes that use /vN to denote versions, and the redundant import alias is still annoying and unwanted.