Move PathFilters from detekt-api to detekt-utils

[BraisGabin]

Also see #6814

We had a little mess around this class. I splitted some tests and move them to the correct locations and then move PathFilters to :detekt-tooling.

We have far too much "utils" subprojects and I'm not 100% sure the responsability of which one, but this one seems the correct one. We don't want this at :detekt-api because it is only used by :detekt-core and by :detekt-cli. And it would be really nice to move it to :detekt-core but, as I said it is also used by :detekt-cli.

If someone create some documentation about which is the responsabilities of each subproject it would be great.

Move PathFilters to :detekt-utils. This class is used on detekt-cli and detekt-core but we don't want it to be part of our public API so I'm moving it to :detekt-utils.

Waiting for #7009

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.75%. Comparing base (731735b) to head (9360ab5).

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #6866   +/-   ##
=========================================
  Coverage     84.75%   84.75%           
  Complexity     3996     3996           
=========================================
  Files           577      577           
  Lines         12133    12133           
  Branches       2486     2486           
=========================================
  Hits          10283    10283           
  Misses          624      624           
  Partials       1226     1226           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[3flex]

Thinking about this, I don't think the includes/excludes belongs in detekt-tooling at all, and it makes sense to remove them from ProjectSpec. Calls to start an analysis session should include the list of files to scan, but the filtering of those should be done by whatever is calling tooling. Different clients will have different methods of filtering file lists.

As an example, the Gradle plugin doesn't pass exclude rules. It already filters and just sends the file list to the CLI. I think it makes more sense to move the path filters to CLI, and remove includes/excludes from tooling and bring everything up a level.

What do you think?

[BraisGabin]

What do you think?

That you are completely right. I'm moving this PR to draft to block it and I'll create another PR removing includes/excludes from ProjectSpec. Then I'll go back to this PR and see if it still have sense or not.

I like to move logic from rules to core. And then from core to clients. The rules and the core are complex enough already.

[BraisGabin]

I rebased this on top of #7009.

Now instead of moving PathFilters to detekt-tooling I move it to detekt-utils. We still use PathFilters on detetk-cli and detekt-core but now it is not part of any API, it is just an implementation detail.

I'm not a big fan of detekt-utils but it is handy to share code between parts of detekt without making it public API.

[BraisGabin]

This PR changed a bit since the last review. @3flex can you take a look again? I see two options here.

1. This PR (move to detekt-utils).
2. Move the code to core and duplicate it on the cli.

Neither of those seems like a bad idea to me.

[3flex]

I'm not a big fan of detekt-utils but it is handy to share code between parts of detekt without making it public API.

Completely agree - it's useful though unless someone comes up with a better idea. LGTM after merge conflict is addressed.