detekt's Path to 2.0 🚀

[cortinico]

Hi all,
We'd love to share the plan for Detekt 2.0, in an effort to be as transparent as possible and get the community onboard with this process. We are really grateful for the role that the Kotlin community has had in the development of detekt, and we believe this is key to reach 2.0.

(Those plans were also presented last week at KotlinConf during the talk: To detekt 2.0 and beyond)

Timeline

1.23.x - released

We'll be releasing 1.23.0 in the coming future, as we have 200+ commits to release to the public: v1.22.0...main
Specifically, you can already try the release candidates for 1.23.x as we're getting close to release stable.

1.23.0 is going to be the last stable release we release from main. Just after the stable release, we'll start to push a series of breaking changes on main.
We foresee potential future releases in the 1.x series, happening from a separate branch.

Specifically, we believe we will be able to ship 1.x versions with:

• Updates to the Kotlin version or other tools
• Fixes for false positives/negatives

2.x

As mentioned, development of 2.x will happen on main. We believe detekt 2.0 stable will be ready by the time Kotlin 2.0 stable is released. We'll most likely still use the older Kotlin compiler to run analysis for Kotlin 2.0 as the Kotlin team is not planning to introduce new language features to Kotlin 2.0

3.x

detekt 3.0 (tentative version number), will be released alongside Kotlin 2.1 and will be using K2. Planning for detekt 3.0 is still pending, and we'll be sharing more in the future.

Modus Operandi

This discussion will have separate threads, one for each item we want to ship in 2.0.
Each item contains a small description of the change we want to do + references to existing issues/discussions. Please refrain from having detailed conversation in this thread, and reuse/open specific issues.
Each item has a status field which describes if it's up for grab or not.
Moreover, each item has an owner field, which should the person that is interested in contributing to this item.

Feel free to comment under the item you want to contribute to.
Make sure you get the item assigned to you by one of the detekt maintainer before starting working on it, as you risk to start working on something that might never land on main.

---

Thank you all for joining us to our journey to detetk 2.0.
If you have doubts or questions, please open separate discussions, as we try to keep this one mostly focused on organization.

On behalf of the detekt maintainers,
— Nicola

[cortinico]

Rename Package & Maven Coordinates

Status 🟢 (up for grab but potentially something we want to do this later in the 2.x development).
Owner: N/A
Brief:

As we own detekt.dev, we should consider migrating all the packages and maven coordinates to it.
(For maven, we should look into specifying a maven relocation)

Importing detekt will make for a nicer experience:

implementation("io.gitlab.arturbosch.detekt:detekt-api:1.22.0")
implementation("dev.detekt:detekt-api:2.0.0")

Plus this will allow us to align the compiler-plugin versioning schema to one similar to the KSP-one

[LeoColman]

What about applying detekt as a plugin? Which coordinate should we use?

[cortinico]

That's up for debate to whoever decides to pick this up. This will have to be discussed as we also have 2 plugins practically (the Gradle one and the Compiler one).

[PoisonedYouth]

Thanks for clarification.

[PoisonedYouth]

Finished.

[cortinico]

This is actually another one we want to include: #6254

[PoisonedYouth]

This is already assigned, correct?

[cortinico]

Yup @segunfamisa is taking care of it

[LeoColman]

I love to remove stuff.
I'm up to work on this one

[LeoColman]

@cortinico I got a notification on this topic but failed to see what changed. Can I start the bulldozer 🚜?

[cortinico]

Not yet 😅

[LeoColman]

@cortinico
dda6b0a

I started with this commit. Should I follow the same idea for other deprecated rules?

[LeoColman]

@cortinico Done in #6193

[cortinico]

Add possibility to instantiate the same rule twice with different config

Status: 🟡 We're accepting proposals on how to implement this feature.
Owner: N/A
Brief:

Users are ending up in scenarions where they would like to instantiate a rule more than once, with different config. We don't have a simple way on how to do it right now.

• Read Test class and function naming: Optional separate pattern for Test files #5412 for further context.

We do have a couple of ideas in mind, but we'd like to discuss further before we deep dive into implementation mode. Proposals are more than welcome.

[BraisGabin]

I'm taking this one. I will update the state in this issue: #6738

[PoisonedYouth]

Which solution is the intended one?

From my point of view changing the behavior of the existing property is a greater change than renaming it.

[cortinico]

IMHO we should remove all the threshold properties entirely as they're confusing and use the allowXXX properties instead.

[PoisonedYouth]

I can take this one.

[PoisonedYouth]

All rules are updated.

[cortinico]

Revisit concept of Severity (Warning vs Error)

Status 🟢 Assigned/In Progress
Owner: @marschwar
Brief:

Currently Detekt has a concept of Severity which is confusing: https://github.com/detekt/detekt/blob/main/detekt-api/src/main/kotlin/io/gitlab/arturbosch/detekt/api/Severity.kt in the sense that you can can specify it but the engine is ignoring it.

This was briefly discussed here: #2680 (comment)

As of today there is no concept of Warning, and we should probably introduce it.

Further discussion will take place in:

• Revisit concept of Severity #6383

[chao2zhang]

There is a good proposal from #6227

[marschwar]

@chao2zhang I saw that you already had a proposal about this in #3274. Would you want to work on it or could I create an initial version? As there are some decisions to make here, I would open a new discussion topic for that.

[chao2zhang]

Please do initiate the discussion 🙏

[cortinico]

Promote Type Resolution to stable and have it as default

Status: 🟢 Assigned
Owner: @3flex
Brief:

For 2.0, we'd love to have Type Resolution as stable and enabled by default. We'll have to find a way to let user toggle this mechanism, as there are users that don't want to run Detekt with Type Resolution (say because they want faster results or are running in a pre-commit hook).

On top of this, the whole detekt vs detektMain thing is really confusing for users. Users need a more explicit way to control TR.

Previous discussions on this:

• Should we remove the "experimental" tag from type-solving? #4959
• Thoughts on hooking detektMain task to Gradle check task? #3122

There are currently two alternatives to this:

• Have a detetkLite/detetkFull task that will take care of running with/without TR.
• Have a Gradle Property on the Task/Extension that will take care of toggling TR (without having to rely on classpaths).

[3flex]

I'll take this!

[cortinico]

Move rules with mixed behavior to run only on Type Resolution

Status 🟢 In progress
Owner @marschwar
Brief
We do have rules that run different whether you have Type Resolution enabled or not, which is extremely confusing. We should move those rules to run only with Type Resolution as they're providing more precise results.

• See Rules with mixed behavior based on Type resolution #2994

[cortinico]

Polish the Gradle Plugin API to be Gradle Idiomatic

Status: 🟢
Owner: @3flex
Brief
We should clean up our Gradle Plugin API to properly us Property<*> and other Gradle idiomatic API.

See:

• Property API for Gradle plugin #1931
• Detekt task outputs are not following Gradle convention #4856

[3flex]

I'll take this!

[cortinico]

Create the stdlib ruleset

Status: 🟢 (Up for Grab)
Owner: @atulgpt
Brief
Our style ruleset is getting quite big.
We should move several stdlib related rules from there and other ruleset into a new stdlib ruleset
This will make style a little bit smaller and easier to handle.

• See stdlib ruleset #3085

[atulgpt]

I can take this

[cortinico]

Assigned. For those kind of issues, please let's first reach alignment on the related issue #3085 and then we can implement them

[cortinico]

Merging Reports & Baselines

Status 🟡 (Needs further discussion)
Owner N/A
Brief
Merging Reports and Baselines is a big friction point for our users.
There are a number of alternatives here to consider:

• We could need different Gradle Plugin between root project and subprojects to implement this.
• Potentially introduce some mechanism to have intermediates raw findings that other tasks can collect and consume (or merge).

Previous conversations here:

• Aggregated Detekt reports #5041
• Support merging of baselines for gradle plugin #1589

[cortinico]

Update CLI path separators to be system dependent

Status: 🟢
Owner: N/A
Brief
Our CLI allows a mixture of path separators (: , ;). We should polish them and this is going to be a breaking change in the CLI.

• Context on this CLI should use consistent system-dependent path separators #1253

[BraisGabin]

Split detekt in multiple tasks/functions that the clients should compose

Status 🟡 (Needs further discussion - it is happening here: #6085)
Owner N/A
Brief
detekt has a lot of integrations so it should be more flexible so it integrates better with other tools. For example, Gradle and it's incremantal build or build cache.