I think it would be nice if we could establish some linter rules in the repository, to avoid further code smells in the future.
Now the full ruleset of ameba would blast with thousands of violations.
But perhaps we could start with a small set, inspired by the recent PRs to at least manifest those in the repository. @Sija@caspiano@veelenga Do you think this would be feasible?
How could we start? Have a big ameba config for opting out of most rules that we currently don’t observe?
I think having the small ruleset for crystal repo will be the best. But perhaps a better idea is to opt-in only to interested rules (instead of opting out of most rules). That will prevent crystal team from changing the config across ameba upgrades. Ameba doesn’t support this right now but this is what we can easily add.
Also, please keep in mind that ameba depends on crystal compiler, and if crystal uses ameba that would be a sort of circular dependency. That means if crystal team introduces breaking semantic or syntax changes that would require incorporating those changes into ameba, only then to lint the crystal repo again. That’s not a big problem but definitely, it will be not the same workflow as for third-party shards.
Yes, I think this would be great!
That’s for integration with big un-linted code bases, not just the compiler/stdlib.
Ideally an integration with --gen-config would be helpful as well. I would think that if you configure only a subset of rules to be enabled (either per opt-in or opt-out), --gen-config could take only that subset into account and generate appropriate excludes for files that violate those rules, but skip all disabled ones.
Additionally, it could point out rules that are disabled but did not find any violations.