Assuming you vendor your tools, you can try go install -mod=vendor golang.org/x/tools/cmd/goimports or go build -mod=vendor golang.org/x/tools/cmd/goimports

Edit: Just realized I misunderstood what you were trying to do

This is more of an issue with -mod=vendor. Possible things you could try are

1. Temporarily set -mod=vendor off.

GOFLAGS='' go get golang.org/x/tools/cmd/goimports

2. Create a file named something like tools.go in the repo that references the tools you'd want to use.

// +build tools

package tools

import (
    _ "golang.org/x/tools/cmd/goimports"
    // and other tools used
)

#30240 may make the -mod=vendor unnecessary in the general case.

#30515 tracks some sort of command (probably a flag for go get) to install a binary independent of the current module.

Note that the argument to go get is a package, and go get some/package implicitly selects the latest version. That version can be arbitrarily different from what is in the vendor directory, so go get -mod=vendor really does seem like a contradictory command.

On the other hand, go get -mod=readonly intentionally ignores the -mod flag, precisely so that you can set it in GOFLAGS. Perhaps go get -mod=vendor should do the same.

Change https://golang.org/cl/198438 mentions this issue: cmd/go: remove the -mod flag from 'go get'

I ran into this problem recently where a CI build was installing github.com/golang/gomock/mockgen so that we could run go generate to confirm any generated files were in sync. However as a newer version of gomock was released, this started updating go.mod with the new version rather than sticking with what was pinned in our go.mod.

Seems the solution was to switch to go install github.com/golang/gomock as we always run go mod download && go mod vendor beforehand and this seems to use the pinned version, or at least doesn't update go.mod. I'm not sure it this is entirely correct, but posting in case someone else stumbles over this issue and is looking for something to workaround.