Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to run diagnostics only on current package #1275

Open
wackywendell opened this issue Mar 6, 2021 · 5 comments
Open

Option to run diagnostics only on current package #1275

wackywendell opened this issue Mar 6, 2021 · 5 comments

Comments

@wackywendell
Copy link

wackywendell commented Mar 6, 2021

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
Copy link
Contributor

hyangah commented Mar 6, 2021

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
Copy link
Author

@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
Copy link
Contributor

hyangah commented Mar 10, 2021

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.

@hyangah hyangah added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Mar 19, 2021
@gopherbot gopherbot added this to the Untriaged milestone Apr 8, 2021
@stamblerre stamblerre modified the milestones: Untriaged, Backlog Apr 9, 2021
@gopherbot
Copy link
Collaborator

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants