Make and promote recommended and shareable presets like in eslint, tslint

[jirfag]

Motivation

1. Some linters are duplicated partially or fully: [errcheck, goerr13, staticcheck], [modguard, depguard], [golint, stylecheck]
2. Some really cool linters aren't used because there are too many linters and only some of them are enabled by default.
3. Configuration became too large. Even maintainers (me too) don't know all configuration options and linters.
4. A common situation is to have multiple .golangci.yml config files because of a lack of extending capabilities.

Proposal

We need to research how eslint, tslint, etc work with that. My first guess is to introduce presets like golangci:recommended and add the ability to share and reuse such presets like airbnb-eslint. Such presets can include any configuration subset: linters, their configuration, output, etc.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[thepwagner]

#2137 is perhaps related, especially when this idea gets into shared presets like airbnb-eslint.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ringerc]

I quickly hit issues with trying to promote a preferred default set of golangci-lint rules for my org, while preserving individual teams' ability to customise, add to and override them on a per-component / per-repo basis. Short of hacks in build automation like pre-processing a .golangci.yaml.d snippets directory to generate a config as part of build automation I didn't find a sensible way to do it.

The lightest-way to satisfy this might be to support a config-directory in golangci-lint like a .golangci.yaml.d. If the configuration points to a directory, all files in that directory are read in locale "C" sort-order and merged. How well this would work will depend a bit on how the config is expressed though; to be useful it has to be possible to match and delete array entries created by earlier configs.

That still leaves the problem of syncing the config snippets to the user of golangci-lint, but the workflow automation that runs the linter can probably take care of that.

[ldez]

Just to link the discussion topic: #3954