-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Custom plugins path should be relative to the configuration file #1085
Labels
enhancement
New feature or improvement
Comments
I also ran this while trying to enable |
What we have ended up doing is leverage a target in our Makefile to dynamically generate the Golint configuration file so that the |
siliconbrain
added a commit
to siliconbrain/golangci-lint
that referenced
this issue
Dec 22, 2020
siliconbrain
added a commit
to siliconbrain/golangci-lint
that referenced
this issue
Dec 22, 2020
ernado
pushed a commit
that referenced
this issue
Dec 26, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I run golangci-lint from a directory which is not where the configuration file (e.g.:
.golangci.yml
) exists, then the custom plugin path is resolved relative to the current working directory, and not to where the configuration file resides.In my case the issue I'm facing is that the vim linter Ale doesn't know what is the root directory of the go module I'm working on, and runs the linter from the package directory with something like:
cd $(dirname $file) && golangci-lint run .
I would like the relative paths from
.golangci.yml
to be relative to the file itself, so that the resolving behaviour would be agnostic to the cwd.In the example below, the plugin will (with latest master) be resolved as
$(pwd)/.go/bin/foobar.so
. I think it should instead be resolved as~/some-project/.go/.bin/foobar.so
, making this deterministic regardless of the current working directory:It's also possible to address this issue without breaking the current behavior by taking inspiration from Jest's
<rootDir>
which is being expanded when the configuration file is loaded. So we could do something like:The text was updated successfully, but these errors were encountered: