detekt-tooling should not depend on detekt-api

[3flex]

Expected Behavior

detekt-tooling should be a stand alone end point that is called by clients (CLI, Gradle, IDE plugin etc). It should not depend on detekt-api.

Current Behavior

It does.

Context

detekt-api dependency pulls kotlin-compiler-embeddable transitively which should not be necessary to interface with detekt-tooling. If the detekt-api dependencies were cleaned up then this wouldn't be an issue, but as it stands, this would be a blocker for migrating the Gradle plugin to call detekt-tooling instead of the CLI.

[BraisGabin]

I agree, remove kotlin-compiler-embeddable from :detekt-api right now is really difficult (maybe impossible).

I see 3 main dependencies:

• KtFile and BindingContext in Detekt.run(Collection<KtFile>, BindingContext)
• Detektion
• Config in DefaultConfigurationProvider

---

The problem with Detekt.run(Collection<KtFile>, BindingContext) is probably the easiest. I imagine that it is ok if :detekt-tooling depend on kotlin-compiler-embeddable only for compilation (comileOnly(libs.kotlin.compilerEmbeddable)). If that's not an option I don't know how to fix it.

Detektion is a class defined on detekt-api that contains the results of the run. This one shouldn't be difficult. We can basically move Detektion to detekt-tooling and that's it. We should change some other classes on detekt-api that depend on that class but it shouldn't be a big problem. Detektion has a transitive dependency with KtElement so same solution as before: comileOnly(libs.kotlin.compilerEmbeddable). Also, #6879 should break that transitive dependency.

About Config, I like the idea that the client should provide a Config instance. This will move classes like YamlConfig or DisabledAutoCorrectConfig outside :detekt-core and that feels good. The problem is that the Rule constructor requires a Config instance to be instantiated so moving Config outside :detekt-api is more difficult. I can imagine different solutions here:

1. Create a :common-api (we should work on the naming). It will contain Config (and maybe Detektion). :detekt-api and detekt-tooling would depend on it.
2. Create a Config2 (same, name pending) on :detekt-tooling and :detekt-core will tranform Config2 to Config so it can be passed to a Rule to be configured.
3. Refactor Rule so it doesn't depend on Config. But I don't like this option, at least not right now.

[BraisGabin]

Other option is to make kotlin-compiler-embeddable compileOnly on :detekt-api. But I didn't think a lot about the implication of that so I'm not 100% sure. Also to make this option a possibility we should finish #7140