Support local .config

[bersace]

Your feature request related to a problem? Please describe.

golangci uses .golangci.yml file on top of project. This clutters root directory of projects.

Describe the solution you'd like.

I suggest to search for .config/golangci.yml too as described at https://github.com/pi0/config-dir

Describe alternatives you've considered.

Using environment variable. This work on CI but is not easy for mates.

Additional context.

No response

[boring-cyborg]

Hey, thank you for opening your first Issue ! 🙂 If you would like to contribute we have a guide for contributors.

[ldez]

Hello,

the configuration of golangci-lint is not a simple tool configuration: it depends on the project and should be committed inside the project.

If you run golangci-lint with the verbose flag, you will see that golangci-lint tries to find the configuration in several places:

$ golangci-lint run -v
INFO [config_reader] Config search paths: [./ /home/user/a/b/c /home/user/a/b /home/user/a /home/user /home /]

I think that ~/.config is not the right place for tools like golangci-lint.

[bersace]

You confused XDG ~/.config and $PWD/.config as described at https://github.com/pi0/config-dir . Please reopen.

Regards,
Étienne

[ldez]

$PWD will not work because you can run golangci-lint inside a package.

To have something that works, we will have to look at all the .config inside the directory tree.

• ./
• /home/user/a/b/c
• /home/user/a/b/c/.config
• /home/user/a/b
• /home/user/a/b/.config
• /home/user/a
• /home/user/a/.config
• /home/user
• /home/user/.config
• /home
• /home/.config
• /
• /.config

[ldez]

🤔 maybe we can do that but the filename will stay .golangci-lint.{yml|yaml|toml|json} (with a dot at the beginning)

🤔 There is a problem with paths, inside the configuration, relative to the configuration position.

[bombsimon]

Since it's fairly easy and cheap to check for a .config directory while we create the search paths I created a PR for this. Although I don't know if we want to support so we can continue to discuss it here but the PR is ready if we decide to accept the request.

[ldez]

My current thought is that we are not ready.

It can feel easy to add the dir to the search (I also did it locally), but we currently have issues with paths inside the configuration as I said here.

Some elements are relative to the configuration path, and some others to the execution path.
Using a path that is not a parent of the project can be a problem.

• Relative paths handling is inconsistent between configuration options, hence unable to run golangci-lint from a subdirectory #3717
• Use path exclude rules on absolute paths instead of relative paths #1178

This is why I put the label no-decision, it needs to evaluate more things.

[bombsimon]

I'm not sure I see the difference compared to when using --config targeting such locations or a global ~/.golangci.yaml, the config would have to reflect that. But of course it would be better if config was consistent independent on where the file is.

I'm not saying that's a reason to add more problematic code and I understand your reasoning!

[bersace]

I guess golangci should build the project root from config path by removing both filename and trailing .config.

[silverwind]

Some elements are relative to the configuration path, and some others to the execution path.

One way of solving this would be to allow the config file to be go code, e.g. golangci.config.go, then the user can take care of path resolution themselves and would ideally only pass absolute paths.

Having the config as code enables many powerful patterns that would otherwise not be possible in static formats like yaml.

[k4yt3x]

Was redirected here after my PR got closed. I actually did a search of the issues and PRs before this and found nothing. Perhaps it'll be helpful to have XDG in the issue's title.

Using a path that is not a parent of the project can be a problem.

While I see the issue that may be created with this,

• it will be nice if golangci-lint can use a default config for projects, even standalone Go files;
• the global config may not have exclusions or other settings that creates relative path issues at all; and
• I'd rather that golangci-lint reads a global config than using no config when one isn't found by looking recursively upwards. I'm also fine if this behavior can only be enabled by a switch/flag, emits a warning or disables exclusions and other rules.

Right now if I want golangci-lint to simultaneously search for repo config and fallback to a global config if the repo config is not found, I'll have to put it in $HOME, which makes a mess in $HOME. Specifying --config in my Nvim args for golagnci-lint or adding default linters in args obviously wouldn't work since if a repo-level config is present it's still going to ignore that.

If the path issue comes solely from having to find the project's root when in a subdirectory of the project, perhaps search upwards for go.mod or go.sum instead? Sorry if I missed some context.

Thanks for making this project. I hope my two cents could be of some help.

[bersace]

This issue is not related to XDG. .config is an universal local config directory for developer tools.

@k4yt3x your use case seems valid and may be implemented with local .config directory anyway.

[k4yt3x]

@bersace so I guess I'm being redirected here not because this is the same issue but only because the comments here are related to what I'm trying to do?

What I'm trying to achieve is not to have a local .config (if I understand your case correctly), but to have one, singular, config in $HOME/.config to serve as the default global config for when one is not specified and none were found by searching upwards, similar to something like, say, rustfmt's global ~/.config/rustfmt/rustfmt.toml. I would, therefore, not consider a local .config.

I'm a bit confused as to what should be done at this point to be honest.

[ldez]

Just to be clear, I didn't say that the PR was a "duplicate" or was about the exact same topic as this issue.
I just wanted to say that the PR was related to this issue because the conclusion and the problems are the same.
I also said to open a new issue if needed.