Option to run diagnostics only on current package

[wackywendell]

Problem

I work in a large "monorepo", with many packages in it. With the default settings for gopls, on save I get 4K+ errors from parts of the repo I don't work on, due to all sorts of setup issues (e.g. setting CGO_CFLAGS) in those packages. I could try and get the setup correct for all of them, but this would be very time-consuming, and I already have the setup working correctly for the packages I am interested in.

Previous Behavior

Before using gopls, I had the setting "go.buildOnSave": "package", and as such, on save I would only see compiler errors for the package I was currently editing. This worked fine with the monorepo. With gopls, this is apparently not an option; as the option text for "Build on Save" says, "Options are 'workspace', 'package', or 'off'. Not applicable when using the language server's diagnostics. See 'go.languageServerExperimentalFeatures.diagnostics' setting.".

Workarounds

I can disable that experimental diagnostics setting (as discussed in #50), but this isn't really what I want, and will likely be deprecated eventually - I'm happy to get compiler errors from gopls, I just want them limited to the current package (and its dependencies in the current workspace), the same as if I called go build . in that package.

[hyangah]

Isn't it possible to utilize "gopls" "build.directoryFilters" setting?
https://github.com/golang/vscode-go/blob/master/docs/settings.md#builddirectoryfilters

cc @stamblerre

[wackywendell]

@hyangah If I only ever worked on one part of the monorepo, yes, I could use that and ignore everything else. However, I often work on different parts, and its nice to have the compiler simply compile whatever package I am working on at the moment, instead of having to keep those filters up-to-date manually.

[hyangah]

Thanks @wackywendell That makes sense.

Does your monorepo have multiple go modules in it?

If not, is it possible to open only the directory that you are working on? I was told recent versions of gopls support opening subdirectories inside a module. gopls will report diagnostics on all files in the module, but vscode won't show diagnostics for files outside of the workspace it's seeing. We are wondering if that's one way to workaround the issue.

But I imagine, in certain situations, working only with one directory of a large monorepo doesn't work.

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

[wackywendell]

Sorry for the delayed response.

Does your monorepo have multiple go modules in it?

It has multiple packages, but it doesn't use go modules; we've had issues transitioning to go modules, and haven't gotten there.

If not, is it possible to open only the directory that you are working on?

Not really; sometimes I start in monorepo/app/foo and then need to jump to monorepo/client/foo and then to monorepo/app/bar which imports monorepo/client/foo. I could open all of those in separate vscode instances... but that's pretty inefficient.