@Fenny thanks for filing an issue. Please answer the following questions to narrow down the underlying issue.

• what's your vscode setting like (any "go", "[go]" prefixed attributes) ?
• are you already using v2 somewhere else (in other packages in the project, or in go.mod, or used in other projects)?

Relevant discussion on Slack: https://gophers.slack.com/archives/CJZH85XCZ/p1601057566019700.
There is also a related issue: #36077.

/cc @heschik

#36077 is not particularly related.

This is a reasonable feature request but I don't think it's trivial, and I'm somewhat disinclined to work on it until the dust surrounding major versions settles. Once the right dependency is in go.mod (and any old ones are removed) the ranking should work okay.

In any case, this is a goimports-specific issue so let's transfer it to the golang/go issue tracker.

@Fenny thanks for filing an issue. Please answer the following questions to narrow down the underlying issue.

• what's your vscode setting like (any "go", "[go]" prefixed attributes) ?

Default settings ( fresh install )

• are you already using v2 somewhere else (in other packages in the project, or in go.mod, or used in other projects)?

Nope, just a blank file without a go.mod, but even if I go mod init <project> it results in the same behavior

@heschik

I'm somewhat disinclined to work on it until the dust surrounding major versions settles.

I suspect that this issue is itself a large part of “the dust surrounding major versions”. (See #40323 (comment) and surrounding discussion.)

If you and @jayconrod agree that a simple "greatest major version is best" heuristic is appropriate for the foreseeable future then I'd probably be more open to it. If there's going to be more work to do to account for retraction and stuff, then I would rather deal with it holistically.

I think the current “whatever is already in use” heuristic is best when it applies, and if nothing is already in use then arbitrarily choosing the highest-version import path is strictly preferable to arbitrarily choosing some other version.

There will probably always be further ways we could fine-tune the heuristic (such as: prefer an import path whose latest release is not deprecated, prefer an import path that has a non-retracted release version, and perhaps others). But I don't think we can figure out how important those fine-tunings are until we fix the properties that we already know are important, such as this one.

Change https://golang.org/cl/261084 mentions this issue: internal/imports: bump relevance for modules with higher major versions