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

support automatically building plugin linters #2566

Open
ashanbrown opened this issue Feb 13, 2022 · 1 comment
Open

support automatically building plugin linters #2566

ashanbrown opened this issue Feb 13, 2022 · 1 comment
Labels
enhancement New feature or improvement linter: custom About custom/private linters

Comments

@ashanbrown
Copy link
Contributor

ashanbrown commented Feb 13, 2022

Your feature request related to a problem? Please describe.

Currently you have to build a plugin locally at a known path prior to running golangci-lint, which creates a challenge for setting up dev and CI environments that use this plugin.

Describe the solution you'd like.

I think one way to address this would be to add a new field, perhaps called "build" to the custom configuration. For example, it might look like this:

  custom:
    gofmts:
      build: github.com/ashanbrown/gofmts/golangci-lint
      description: gofmts sort formatter
      original-url: github.com/ashanbrown/gofmts

What I think this would do is run:

go build -o <some path in the cache>/plugin.so  --buildmode=plugin github.com/ashanbrown/gofmts/golangci-lint

and then auto-determine the path field based on where the plugin is built.

This appears to work within a module-based environment that also includes golangci-lint in the go.mod file.

The one question I have is where the plugins would be stored. We use a cache directory that is shared between versions of golang ci lint (on my mac its ~/Library/Caches/golangci-lint/) and the plugin.so files need to be built for a precise set of dependencies, so the path to the plugin file should probably be some hash including all of the dependencies. Despite the shared cache, it might make sense just to have a plugin per package/plugin pair and ignore the dependencies in the path, so that we don't leak old plugins.

Describe alternatives you've considered.

I think think the alternative is to instrument dev and CI environments to build the plugin themselves.

Additional context.

No response

@ashanbrown ashanbrown added the enhancement New feature or improvement label Feb 13, 2022
@ldez ldez added the linter: custom About custom/private linters label Feb 13, 2022
@dnephin
Copy link

dnephin commented Sep 12, 2022

I wrote a custom plugin for golangci-lint recently and ran into all the same problems.

I was able to script the module versions using the output of go version -m and the golang.org/x/mod/modfile package. You can see an example of that here.

Unless the developer has built golangci-lint locally, I don't see a way to automatically deal with the Go version.

Is part of this proposal to also built golangci-lint locally? It seems like if the binary for golangci-lint comes from a package manager or a pre-build binary, there's no way to build the plugin with the correct Go version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or improvement linter: custom About custom/private linters
Projects
None yet
Development

No branches or pull requests

3 participants