Open hochhaus opened 7 months ago
Not yet. I probably won’t have the bandwidth to work on it for several months.
I could help review such contribution though.
I had a chance to take a quick look at this problem I was preparing for v0.0.3 release and tbh, it's not yet clear to me how to solve it.
The problem is that today, I am managing the dependencies in this repo with go.work
and multiple go.mod
files inside that workspace. This allows me to create smaller deps.bzl
for downstream users to only include what they need.
For example, if you only use //staticcheck
portion of the repo, you will not need to import everything in //golangci-lint:deps.bzl
.
This, however, is hard to do with bzlmod.
First of all, you would need to switch the dependencies management over to gazelle.go_deps
extension, which is a monolithic approach leveraging the current Go module system. So that would require me to include a bunch of dummy.go
into different packages to expose the upstream dependencies to downstream users. A bit yuck, but ok.
Secondly, when users import nogo-analyzer dummy packages as tool dependencies via go get
, that would subject nogo-analyzer
to Gazelle's go_repository build file generation, which lack the extension we need. 🤔
Lastly, if the BUILD files are overridden, then we will face a problem similar to https://github.com/bazelbuild/bazel/issues/19301, which is still a blocker.
I briefly considered rolling my own bzlmod extensions to generate the go_repository
myself. But it could be quite some complexity to maintain and it's unclear how the conflict with Gazelle's go_deps would be resolved.
So I think I will wait a bit longer to implement Bzlmod support for nogo-analyzer
. Folks could still use the repo today with WORKSPACE.bzlmod
file.
And if any contributors is willing to work on bzlmod support, I could give the PR a review.
Does
nogo-analyzer
support bzlmod? If so, could a section be added to the documentation stating how to set it up?