Can you clarify how go/types doesn't work with modules? It's perhaps not trivial to set up correctly, but it certainly works with modules. Over half of the Go tools out there which support analyzing Go code with modules do use go/types.

An example of a tool that supports modules and uses go/types directly: https://github.com/burrowers/garble/blob/2e2bd09b5e420455f51f7e1e1cbe46a11a6a7cf3/main.go#L409-L413

Granted that it's a complex file and not a very clear example, but just to prove a point. I agree that better docs would be nice, but they should definitely not say "does not support modules".

hmm... lemme recheck what I was doing. I have an incredibly basic test that fails, but I may be making a simple mistake.

I heard from twitter that go/types didn't work with modules and ... probably should have double checked that assertion :) Lemme get back to you in a bit.

I think the reply you got on Twitter is mostly right; most tools which just want to load Go packages should use x/tools/go/packages, which uses go/types under the hood and supports modules. But it's certainly possible to use go/types directly and support modules at the same time. Another way to think about it - if go/types simply did not support modules, how would go/packages support modules and expose go/types.Info etc?

I think I have an idea of the problem I was having. I am running tests that parse go files that exist only for testing purposes (under /testdata). Those testdata files sometimes include 3rd party imports that the main program doesn't have, so they're not in the go.mod or go.sum. I presume this screws up go/types, since it doesn't do the auto-download of imports the way the build tools do.

Previously I was just using go/ast to parse them, and it doesn't care about imports, so these tests worked fine.

Yeah, ok, no, that's not it either.

here's my test:

$ go run main.go
2020/12/14 10:59:15 exec: echo foo
foo
failed to check types on files in ./foo/: foo/foo.go:4:2: could not import github.com/magefile/mage/sh (can't find import: "github.com/magefile/mage/sh")

main.go

package main

import (
	"fmt"
	"go/ast"
	"go/importer"
	"go/parser"
	"go/token"
	"go/types"

	"play.ground/foo"
)

func main() {
	foo.Bar()
	fset := token.NewFileSet()

	path := "./foo/"
	f, err := parser.ParseFile(fset, "foo/foo.go", nil, 0)
	if err != nil {
		panic(err)
	}

	info := &types.Info{
		Defs:  make(map[*ast.Ident]types.Object),
		Uses:  make(map[*ast.Ident]types.Object),
		Types: make(map[ast.Expr]types.TypeAndValue),
	}

	conf := types.Config{Importer: importer.Default()}
	if _, err = conf.Check(path, fset, []*ast.File{f}, info); err != nil {
		fmt.Printf("failed to check types on files in %s: %s\n", path, err)
	}
}

foo/foo.go

package foo

import (
	"github.com/magefile/mage/sh"
)

func Bar() {
	sh.RunV("echo", "foo")
}

go.mod

module play.ground

go 1.15

require github.com/magefile/mage v1.10.0

Seeing your example, I still think that your answer here is that you should be using go/packages, which will do all the modules resolution for you. go/types can support modules via its importer interface, but it doesn't do so out of the box on its own, because it is a typechecker, not a build tool that understands what modules are.

Closing as a duplicate of #28328 and #31821.

But also note that trying to use the importer interface yourself directly is not a great idea; see #44630. This is another reason why you should just rely on go/packages.