Spot some issues with elvis.config (non-existing modules, non-existing rules)

[bormilan]

Description

I made a little refactor on the elvis_config:validate using maybe. Feel free to roast it; I'm still experiencing this feature and its capabilities.

I skipped the validation of the rule configs in this step. (Should I implement it too, or is it okay to leave it for later?)

Now this solution can:
- spot if a non-existent module was given in the elvis.config
- spot is a nonexistent rule(for an existing module) was given in the elvis.config
- spot any other issues that were implemented in the past

I have a test that I commented out because I'm not sure what it was intended to test 😅 (I marked it in the files)
I see that it skips to load a module called user_defined_rules, but I'm not sure whether I need to keep this test or change it to expect my new error message.

Also, I want to add more tests, so feel free to suggest some if you have some cases.

Closes #389;.

• I have read and understood the contributing guidelines

[bormilan]

I'm planning on adding:
- spot non-existent rulesets
- spot invalid rule config
- spot non-existent dirs
- spot non-existent filter

I don't know whether I should do all in this PR or cut it into smaller tasks

[paulo-ferraz-oliveira]

I made a little refactor on the elvis_config:validate using maybe. Feel free to roast it; I'm still experiencing this feature and its capabilities.

I think it's Ok to keep, since it's now part of the language and inside our support scope, but I did leave a comment on maybe how to improve the current implementation's readability.

I skipped the validation of the rule configs in this step. (Should I implement it too, or is it okay to leave it for later?)

For me it's Ok to leave for later; just open a ticket 😄

I have a test that I commented out because I'm not sure what it was intended to test 😅 (I marked it in the files) I see that it skips to load a module called user_defined_rules, but I'm not sure whether I need to keep this test or change it to expect my new error message.

Yeah, I commented on this. I'd keep the test if it wasn't failing, and add a comment on its intention if you can find it in Git history. Just removing it (or commenting it out) while implementing a new feature seems odd.

I like the general direction, and have left a few comments.

Edit: I tweaked the PR title since it'll be used for the generated changelog. Feel free to re-tweak if we decide on changing scope.

[bormilan]

Currently, I just don't know how to fix builds.

If I make a vm.args with the content of -enable-feature maybe_expr and run the ERL_FLAGS="-args_file config/vm.args" rebar3 test command, the build will run successfully.

But since it's a file path, in the Windows builds, I need to change it, so I need to find a way to change the CI a little bit to execute rebar commands with the proper ERL_FLAGS.

[elbrujohalcon]

Yeah, @bormilan … I don't know what's the deal with ex_doc and maybe… but I would be super-pragmatic and… just don't run ex_doc in OTP25. Period. Even more, we can just not run ex_doc in anything lower than the latest version we use for CI (i.e. 27).

[paulo-ferraz-oliveira]

@elbrujohalcon, should we flag old_configuration_format as deprecated in the scope of this change (or later, if you prefer to separate stuff)? We can also remove it while keeping the documentation for historical purposes...

[elbrujohalcon]

@paulo-ferraz-oliveira yeah, let's remove it. But maybe outside this PR, just so this PR can be merged with the fix for CI pipelines :)

[elbrujohalcon]

I think the PR is good as it is, but I left a tiny nit-picky comment for tests.
I also didn't check around to see what we usually use, but if we use pattern-matching everywhere instead of ct:fail/1,2, do ignore my comment.

[bormilan]

I'm planning on adding: - spot non-existent rulesets - spot invalid rule config - spot non-existent dirs - spot non-existent filter

I don't know whether I should do all in this PR or cut it into smaller tasks

I will open a ticket(or more) later in this week, or maybe a discussion first, about these.

[paulo-ferraz-oliveira]

@bormilan, you have merge rights, correct? If so, it feels like you can go ahead and merge this.

[elbrujohalcon]

Well… now you have to resolve the conflicts, @bormilan … but after that go ahead and (if CI is green) merge the thing.

[bormilan]

It's strange that the test, verify_no_single_match_maybe, is failing for me locally.
I need to add the ERL_FLAG... to the command to make it work.