/cc @bcmills

Hi @mihaiav, is your example a case where go get in 1.11 seems to work for you to get X, but go mod vendor fails for X? Or does go get in 1.11 seem to exhibit the same issue you are reporting for go mod vendor?

I suspect you have a few options, but probably worthwhile to say a few more words about your goals.

Vendoring with modules in 1.11 might be one approach that ends up working out for you, and that might be the simplest answer.

That said, an alternative approach might be one of a few different options involving GOPROXY environment variable.

For example, GOPROXY=file:///filesystem/path environment variable tells the go commands to use a filesystem (local or remote) to resolve dependencies, without any need to have an actual running proxy process. In general for modules, the go command (e.g., go get or go build) automatically stores downloaded dependencies in its local cache ($GOPATH/pkg/mod), and its cache layout is the same as the requirements for a proxy, so that cache can be used as the content for a filesystem-based GOPROXY or simple webserver used as a GOPROXY. In addition, go mod download populates $GOPATH/pkg/mod/cache/download, which means that command can be used to pre-populate or update the contents for a GOPROXY. You can read some more details in the tip documentation, especially the description at the end of that 'Module proxy protocol' documentation section.

Also, here is a nice end-to-end example from @myitcv of using GOPROXY with a filesystem:
https://github.com/myitcv/go-modules-by-example/tree/master/012_modvendor

However, the best approach likely depends on exactly what you are trying to do, and what your exact constraints are.

go mod vendor does work offline if all of the modules are already in the local module cache (e.g., after a successful go mod download).

Bootstrapping an unpublished module into the module cache is a separate problem, for which I've filed #28835. I'd rather do that than copy the source directly into the vendor directory, since there is some metadata there (in vendor/modules.txt) that expects vendor contents to match the actual modules. (See also #27348.)

You should be able to set up a replace directive pointing to the local filesystem, then run go mod vendor to copy the replaced source into the vendor directory.

The mod_vendor_replace test verifies that behavior. It's part of the fix for #27859, so you may have to build from source (from commit f8153fc or later) to pick up that fix.