Sharing Configurations Across Repos, VSCode go.linter config

[natefinch]

At work, we have a shared golangci configuration that lives in a github repo, github.com/github/go-linter.

I'm trying to figure out how best to share that configuration across many go repos. I've heard that other languages use their package managers to handle pinning a version of the linting config, and I thought that sounded like a good idea. I can get that to work, mostly.

In the go project, we add a

import _ "github.com/github/go-linter"

Which then pins a version of the go-linter code in our go.mod.

I can then call golangci-lint using the config file in that go-linter module by using this command from the terminal:

golangci-lint run -v -c $(go list -f '{{.Dir}}' -m github.com/github/go-linter)/.golangci.toml

Cool. Now I can run that locally and in CI, and always use the same pinned version of the config file referenced by the project's go.mod file.

However, there doesn't immediately seem to be a way to get VSCode to use the same setting for it's lint-on-save functionality. You can't set this in your settings.json:

"go.lintFlags": [
    "-c",
    "$(go list -f '{{.Dir}}' -m github.com/github/go-linter)/.golangci.toml"
  ],

It doesn't work (and probably shouldn't.... I don't think we want our settings file to be able to run arbitrary bash commands).

But I'm not sure how to solve this conundrum - using the correct linter config in vscode is super important to avoid having to wait for CI to find linting errors.

Any suggestions would be welcome. Ideally, I'd like to use go modules to pin the config version, but I'd consider other solutions (aside from git submodules... I know someone is going to suggest it, and just... no).

[ldez]

Hello,

I don't have the answer about VSCode but I'd like to discuss shareable configuration.

The (remotely) shareable configuration seems to be a common problem, I started to reference all the issues and PRs about this because we have to be able to provide an "official" solution/answer.
Currently, we have the stdin trick that you are using.

I've been having a look at your idea of using a Go module to embed a configuration file, and I've come across an issue.
Your module will be versioned (to be able to pin the config version) but the version of the module will be handled by MVS.
So if a dependency uses a more recent version of your configuration's module, your project will use the more recent configuration. (the replace directive could be a workaround but it doesn't seem to be a good solution to me)

[natefinch]

That's an interesting point.

I think the main drawback to this experience is that it's unexpected behavior. You update the version of your company's logging package, and suddenly get a bunch of linter errors that weren't there before.

I think a replace directive is almost as good as any other solution. Any solution is going to require you to write down the specific version of the config you want and update it by hand whenever you want to update the version of the config you use.

I guess the other option is to build this into golangci-lint itself. That is probably the most straightforward way, which would be easy for people to understand, and doesn't leave them subject to the oddities of the go module system.

I'd like to have a way to specify this in a file on disk, so I don't have to run a special CLI command for golangci-lint to work. It would be nice if golangci-lint run would Just Work whether I have a local config file or a remote config file.

Maybe something like .golangci-remote.yml with

repo: github.com/github/go-linter
file: .golangci.yml
tag: v1.1.0

Then golangci-lint could do a shallow git clone of that repo at that tag to get the config file.

You could offer a purely url-based version as well, but I bet for most uses, this would be a company-specific private git repo and thus not available without the authentication you get through git.

This would also solve the problem of getting vscode to do the right thing, because the regular command without a flag would pick up the remote-config file and work correctly.

It would also be nice not to have to slap a import _ "github.com/github/go-linter" in our code somewhere for no real reason.

FWIW, this page seems to have pretty good instructions for how to do a minimal git clone when you only want a single file. You may already know how to do that, but I didn't :)

[ldez]

The way to get the configuration is one item of the set required to have something shareable.

I had already managed hundreds of projects throughout a company, but I was unable to establish a successful standard/common configuration.

The problems are coming from several points:

• issues configuration (mainly issues.exclude and issues.exclude-rules)
• run configuration
• the linters used
• linter configurations

Note: I prefer issues.exclude-rules over nolint directives, but it's another topic.

The history and the constraints of each project are different, a common configuration will lead to a weak configuration because you have to pick only the linters and the configurations that work for all projects.

I am led to believe that a shared configuration should support merging or being partial/fragmented or templating.

[natefinch]

I set up a standard configuration and encourage everyone at GitHub to use it. There has been pretty good success with getting projects onboard.

In my opinion, having a single standardized linter configuration is the whole point, both so new projects don't have to configure it themselves, and also to enforce some coding standards across the company.

We occasionally get some pushback from different projects that don't like one or another linter or the configuration for them... and occasionally that means we change the config, but that doesn't happen that often. Usually I can explain why a particular linter is valuable.

I really only use exclude rules to ignore test files for select linters. Otherwise, I really dislike them, because they operate as a kind of invisible configuration override that can be surprising if you don't know to look for it.

I like nolint directives, because they're intentionally noisy. So if we have to write too many of them, it's clear that either there's a linter that should be disabled, or we have problems with the way we're writing code.

[hu3bi]

I love the entire discussion and where this is going.

One compelling idea is to support merging configuration files and automatically detecting when to enable situational linters.

For example, some linters are relevant only to specific projects. sqlclosecheck, for instance, might not be necessary everywhere. It would be helpful to have a detect command that scans your codebase for usage of packages like SQLite and suggests enabling sqlclosecheck if appropriate. This approach could extend to other situational linters as well.

Summary (TL;DR):

1. Define a default linter configuration.
2. Other projects inherit or extend this default config.
3. Provide a command to detect which situational linters should be enabled (but only if they’re included in the default config).
4. Declare any situational linters required by your project.
5. Merge the default config with project-specific situational linter settings.

@ldez @natefinch

[dangoor]

One option might be to create a frontend program for golangci-lint that embeds the config. Not necessarily ideal, but could be good in a company environment with a lot of developers.

[ldez]

One option for a company with a lot of developers might be to sponsor the maintainers to have the time to handle this:

• https://donate.golangci.org/
• https://donate.ldez.dev/

As I said, "we have to be able to provide an official solution/answer" but this requires time to find the right approach (PRs don't help with the type of topic).

I don't want to be rude, I always feel bad about this kind of proposal that doesn't really help us.

[elrayle]

I haven't worked with golangci-lint enough to know if this can work, but want to provide an example from Rails that worked extremely well for Rubocop.

• samvera/bixby holds prescriptive shared rubocop configs
• repos include that gem in their Gemfile or reponame.gemspec files to bring it in as a dependency
• in the repo's rubocop config
  • inherit the bixby config which gets the shared configs
  • make any overrides needed for that repo

[ccoVeille]

I've considered building a tool to configure golangci-lint

But when I started consider it, I found difficult to imagine a tool that would suggest

So yes, predefined config would be better, but then it would be opinionated.

The default version provided with golangci-lint works with most projects.

But as with any other linters, the linters you need depend:

• your codebase
• the quality of your codebase
• the motivation of the people working on the repository are likely to fix issues
• if you want to block merge request via CI, or you want non blocking rules.
• linters should/can only be added by iteration

[ccoVeille]

The other issues is that enable linters is somehow a journey.

My fear is that it could lead to bring extra work to golangci team (via issues, questions, or requests) while it shouldn't.

[ccoVeille]

Here is the file I usually configure on project

Talento90/goliath#7

I'm pretty sure, it won't fit most need as it's pretty complete and opinionated.

But I went to far compared to the initial request that seems talk about inheritance from other project, which is indeed complicated

[mskonovalov]

Just for the context for those who may not be aware I'd like to add how this is managed in JS/TS world:
if we look at eslint, it allows you to import some external config and then override everything that you like for the specific repo.
thus there are some "golden" configs from big companies like e.g. https://github.com/airbnb/javascript/tree/master/packages/eslint-config-airbnb-base or just officially recommended configs
And then in your projects config you can import it and extend/override like that

{
  "extends": [
    "airbnb-base",
    "plugin:@typescript-eslint/recommended",
    "plugin:prettier/recommended",
  ],
  "rules": {
    // here comes overrides
    "no-console": "off"
    ...
  }
}

[gnattishness]

Viper provides built-in support for merging configs and configuration via environment variables.

I imagine there may be good reasons why these have not been used to allow merging or overriding shared configs, but I don't see it discussed elsewhere.

Some of the issues that link to this discussion also mention possible override UX of:

• a .config.d/ containing overrides
• providing the CLI argument --config multiple times, with each being merged into the previous

These are flows that are external to the config, in comparison to the config itself supporting overrides using an "extends" field>
They are also more simple, in that they make no attempt to address sourcing a remote config.