Improve rulesets with default values

[bormilan]

Add functionality for adding different default values to rulesets.

Example: The default max value for max_function_length would be higher in test modules.

[paulo-ferraz-oliveira]

For this we can use custom rulesets, right? Unless I didn't understand their initial goal :) we can extend them allow for what you propose, maybe (?)

[bormilan]

Do you mean to make custom rulesets work in a way where you can set the configurations for the rules?
I like the idea of giving the power of creating custom things to the user, but I often find myself lazy and just use the given sets. I think a lot of users would prefer using pre-made rulesets over creating custom ones for themselves.

[paulo-ferraz-oliveira]

I agree many (most?) consumers will prefer presets, but maybe this way (making for a generic implementation) you can then solve the problem easily too (and give an extra config. option), as it'd allow us to manipulate the rulesets with a few tweaks.

Let's say something similar to:

{extends, erl_files, #{
    updated_rules => [{elvis_style, max_function_length, #{max => 500}}],
    % ^ if not defined in the target ruleset they'd be added to avoid an extra key
    disabled_rules => [{elvis_style, dont_repeat_yourself}]
}}

As an example, eslint allows you to not only extend but write plugins for it 😉

[elbrujohalcon]

Hey, folks…

1. We already have a mechanism to allow users to define their own rulesets: Allow for custom rules in elvis configuration #141.
2. There is currently no way to define a ruleset based on another (where you would add disabled_rules =>… or extra_rules =>…). This might be a good addition but, given the sparse use of this feature, I would not devote too much effort into this addition.
3. Adding default values to rulesets is a good idea. We should both add them to our predefined rulesets (particularly useful once we add one for tests) and allow custom rulesets to add them, too.
4. But… I wouldn't go too far beyond that. If people want to use x ruleset, but with their particular options… they can already do that in any config section they want (i.e., ruleset => x, rules => […all the specific config things…]). That should be enough, I think. If they don't want to repeat that all over the elvis.config file, fine… they can define a custom ruleset with their options (once we have implemented this change).

[elbrujohalcon]

Well… I found the docs: https://github.com/inaka/elvis_core/blob/main/RULES.md#rulesets
But… either that's correct, we can already allow people to parameterize the rules in their rulesets… or (more likely) that documentation is wrong and the definition of a custom ruleset can only contain atoms…
In any case, the goal of this ticket should be to comply with that documentation 😄

[elbrujohalcon]

…and allow us to define our own rulesets like that (i.e., with parameters for the rules).

[paulo-ferraz-oliveira]

1. 👍
2. 👍
3. what syntax do you propose for this? My goal, for updating a ruleset, would be to start with what we have, and tweak; the defaults are just that, defaults, but if we wanna have a way to allow custom rulesets to override them we could use them ourselves, too
4. 👍

[elbrujohalcon]

For #3… I would use the syntax from the docs 😉
In other words: a list of atom() | {module(), atom()} | {module(), atom(), config()}
But once again, I would not allow people to define rulesets by "overriding" existing ones. If they want a custom ruleset, they need to explicitly list all the rules. It's not so complex and it saves us a lot of inheritance headaches.