Hi @stamblerre - has anyone started this? Thought I could give it a whirl.

No I don't think anyone has! Please go ahead.

The code you'll want to look at is here. We'll probably need to detect if the package is an allowed internal package and then add an error. Here's the formal documentation for internal packages: https://golang.org/cmd/go/#hdr-Internal_Directories.

Sound good! Thanks for the pointers.

One question - is it safe to rely on the pkgPath from the metadata passed in to typeCheck to compare against the imported pkgPath? I've been seeing it set to command-line-arguments during my testing, although it may be just that my VSCode has a misconfiguration.

command-line-arguments can mean that your package is both outside of GOPATH and outside of a module, so if that's your setup then you may see that. But, yes, in general it is safe to compare these package paths.

Great - I created a PR here.

While looking through the code, I found an alternative way to perform the check (using the analysis API) which seems to have the benefit of working with the gopls CLI as well as the server. I'm unsure of the performance comparison with using the lsp cache, but just thought I would mention it in case it had merit.

Anything in the gopls codebase will work with both the CLI and the server, so your change is the correct solution - thank you!

The analysis API is typically for analyses on top of type-checked code, but in the case of a package with an invalid import, it really shouldn't even type check. We could potentially add a diagnostic instead of failing to type-check, but that would have the misleading effect of showing users completions that won't compile.

Fixed via CL 218977.