Warn on resolved exceptions about elvis_core HOT 9 OPEN

@paulo-ferraz-oliveira what @onno-vos-dev wants is a warning that's emitted when there is an ignore rule that is effectively ignoring nothing… and therefore it's an useless ignore. Like the warning that we emit when a file/dir configuration block actually affects 0 files.

from elvis_core.

In theory you could simply have two config files (say elvis.config and noignores.elvis.config) and periodically run with the noignores version to verify if you still need to ignore your modules, right?
You can even have an inverse.elvis.config that's configured to run only on ignored files.

But, in any case, I'm not opposed to providing a command-line option to ignore the ignores so that you can run $ elvis --no-ignores and it will disregard the ignore configs.

from elvis_core.

That was my kind of thinking. One of the projects that I work on is merging multiple configs from different teams into one before running elvis on the diff between the current branch and master. Creating an noignores.elvis.config or inverse.elvis.config would be quite problematic.

I'll try to implement some form of --no-ignores functionality 👍

from elvis_core.

Keep in mind we have ignores both at group level…

[
 {
   elvis,
   [
    {config,
     [#{dirs => ["src"],
        filter => "*.erl",
        ruleset => erl_files,
        ignore => [this_module, that_module] %% <== THIS
       },
…

…and also at rule level for some rules, e.g.

{elvis_style, invalid_dynamic_call, #{ignore => [elvis]}}

I'm sorry I can't link to proper docs (I already opened inaka/elvis#489 to fix that) :(

from elvis_core.

When I wrote my idea above I was thinking only about the ignore at group-level, but considering our conversation in inaka/elvis#488 I guess you also want to ignore the individual per-rule ignores, right?

from elvis_core.

I got confused with so many ignores. What's the main goal?

from elvis_core.

As per the previous question, is this something we still need to pursue, or can the issue be closed?

from elvis_core.

Oh, that makes sense. I like it. We need to keep state, though, right? At the file level, for file-level config., and at the project level, for project level config. (actually, for module, module/function and module/function/arity, also).

from elvis_core.

Yeah, it's not trivial by any means.

from elvis_core.