There has been some previous discussion about this in some other issues: #1182 <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="667025377" data-permission-text="Title is private" data-url="https://.com/golangci/golangci-lint/issues/1276" data-hovercard-type="issue" data-hovercard-url="/golangci/golangci-lint/issues/1276/hovercard?comment_id=665903858&comment_type=issue_comment" href="https://.com/golangci/golangci-lint/issues/1276#issuecomment-665903858">#1276 (comment) <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="667025377" data-permission-text="Title is private" data-url="https://.com/golangci/golangci-lint/issues/1276" data-hovercard-type="issue" data-hovercard-url="/golangci/golangci-lint/issues/1276/hovercard?comment_id=1304872725&comment_type=issue_comment" href="https://.com/golangci/golangci-lint/issues/1276#issuecomment-1304872725">#1276 (comment) Since some of those weren't totally relevant to the attached issues and/or closed, I thought it might make sense to start a new discussion about ways that it might be possible to use prebuilt golangci-lint binaries with plugin support. As I understand it, there are a few requirements needed to support Go plugins (copy-pasting from <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="4437562" data-permission-text="Title is private" data-url="https://.com/golangci/golangci-lint/discussions/3259" data-hovercard-type="discussion" data-hovercard-url="/golangci/golangci-lint/discussions/3259/hovercard?comment_id=3778846" href="https://.com/golangci/golangci-lint/discussions/3259#discussioncomment-3778846">#3259 (reply in thread) for reference): exact same Go version same OS/arch same version of shared dependencies CGO_ENABLED=1 during build I believe (although not 100% positive) that for the first three of these, the Go runtime verifies these and refuses to load a plugin if these conditions are not met. I am also under the impression that CGO_ENABLED=0 is used when building releases to improve portability for the distributed binaries. Although it's not clear to me exactly how, I can understand that there might be two use cases here: more portable + no plugins less portable + plugins With that in mind, does it seem like a reasonable option to publish two versions of the binaries, one with plugin support ( CGO_ENABLED=1 ) and one without? Existing users could continue to use the same binaries they already use without any change, but custom plugin support (within the constraints listed above) would be possible without requiring a build from source. Barring any functional changes like publishing plugin-compatible binaries, I think there might be two things that would help users understand what's going on with the status quo: As mentioned in #1276 , if possible, detect configuration for custom linters and print a warning/error if the binary was built with CGO_ENABLED=0 since it will never be able to load those custom linters. Update docs in https://golangci-lint.run/contributing/new-linters/#how-to-add-a-private-linter-to-golangci-lint to explicitly mention that building from source with CGO_ENABLED=1 is required. Currently the docs don't seem to mention building golangci-lint itself at all, and only mention building the plugin, which is a bit confusing since really both appear to be required for the custom linter to work.

Hello, it's not possible to pre-build something compatible with plugins because the plugin and the binary must be built with the same Go stack/environment. CGO_ENABLED is only one of the requirements.

Prebuilt binaries supporting plugins / custom linters · golangci golangci-lint