chore: adds golangci config

[CLoZengineer]

No description provided.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Christopher Lowenthal seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[seebs]

this seems insane. cyclomatic complexity isn't a great metric at the best of times, but ten? That's very solidly into "this is broken up into so many tiny pieces that reasoning about the tiny pieces becomes overwhelming" territory, I think.

[CLoZengineer]

I think this will come down to a case per case basis.
But I'd like to keep this at the default for now, and we will adjust it as the code quality is tightened up.

[seebs]

do we benefit from having both this and the cyclomatic thing? my default preference would be "neither" really.

[CLoZengineer]

as we're starting this I'd rather maximize signal, and deal with noise later.
Though to your previous comments, I updated this to its default of 30"

[seebs]

I'm concerned about the sheer volume of new linting here and want some idea what this reports and how much of what it reports is noise. Also, I'd really like to have all the things that say "deprecated, use [...]" be not-used, because that just seems like asking for trouble.

[CLoZengineer]

Agree with you @seebs. I just started with the reference and I've been pairing back.
I tend to find that with config files, if you start blank and add, you end up missing a lot of options. But when you pare them away, you're actively thinking of them before you do.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[seebs]

i think it makes sense to have *testing.T in that list, but if we don't happen to actually be using it, that doesn't seem important, we can always fix it later if we care.

[seebs]

This seems like a reasonable starting point to me. I'm assuming that this won't result in a situation where we can't merge any changes until we make hundreds of large and intrusive changes, though, if I'm wrong, don't merge it yet. :)