Report or fail build when kotlin-compiler-embeddable version is overridden

[3flex]

Expected Behavior

detekt runs successfully using the expected version of the kotlin-compiler-embeddable dependency. If the version of the dependency is overridden in the user's build, either warn the user or fail the build, with a link to documentation explaining the issue and some ways to deal with it.

Current Behavior

This keeps coming up as an issue that detekt doesn't properly handle.

Context

#5644 #5582 #5551 #5021 #4786 #4287

[cortinico]

I think this would be really valuable.

either warn the user or fail the build

Are you suggesting querying the kotlin-compiler-embeddable version at Detekt Gradle Plugin apply() type and raising a warning there?

[3flex]

That was my initial thinking.

But actually I think a more robust method is to check it in detekt-cli. We can check org.jetbrains.kotlin.config.KotlinCompilerVersion.VERSION against the expected Kotlin compiler version before starting any analysis. We just need to embed the expected Kotlin version in the JAR somewhere to query.

What do you think about that approach?

[cortinico]

What do you think about that approach?

Yup that also works 👍 I'd say that firing a warning + linking to a issue/page that explains this would be the way to go

[3flex]

I'm going with a failure instead of a warning - even if the mismatched Kotlin version might work (which can happen if it's just a difference in minor version, e.g. 1.7.0 instead of 1.7.10) it will eventually end in failure if not corrected. A warning might be lost in the noise.

But 100% agree on linking to a doc page with pointers on how to correct it.

[cortinico]

I'm going with a failure instead of a warning

I thought a bit about it, and maybe this ends up being too aggressive? We would be the only Gradle plugin in the ecosystem doing this. We can't expect every user to align on the Kotlin version we impose (i.e. we're not compose).

even if the mismatched Kotlin version might work

I actually think this gives us more freedom as otherwise we might be forced to release a point release whenever Kotlin releases

EDIT: typo

[3flex]

We can expect

Assume you meant "can't"?

In any case, that's not the expectation - remember that detekt has its own dependency configuration, which requires a specific Kotlin version. The project itself can use any Kotlin version it likes and detekt doesn't impose a specific version for the project.

However the project should not override detekt's dependency configuration otherwise there will be unhandled errors, or with the PR, at least there's a more useful error with a link to the docs to allow users to fix it themselves.

[cortinico]

Assume you meant "can't"?

Yup that was a typo of mine.

The project itself can use any Kotlin version it likes and detekt doesn't impose a specific version for the project.

When you say the project itself you mean the runtime right? What happens if a user is applying another gradle plugin which includes a higher version of kotlin-compiler-embeddable? Are we going to fail the build for this?

[3flex]

When you say the project itself you mean the runtime right?

Any other dependency configuration except the detekt dependency configuration. detekt dependency configuration needs a specific version of kotlin-compiler-embeddable so it's available on the detekt classpath when it runs. It doesn't matter what version of Kotlin is used for any other dependency configuration.

What happens if a user is applying another gradle plugin which includes a higher version of kotlin-compiler-embeddable?

If the plugin is overriding the dependency version used in the detekt dependency configuration then yes, the build will fail. My view is that the plugin either has a bug, or is misconfigured, if that happens. Do you know of any plugins that are overriding dependencies on all dependency configurations?

The other alternative is just to give up on this approach and have the Gradle plugin use the uber jar as the dependency. That should solve things for good but has other drawbacks.