Hi. What is the motivation to copy over ktlint rules? We always assumed detekt to be semantics check...

# detekt

[Jan Skrasek]

Hi. What is the motivation to copy over ktlint rules? We always assumed detekt to be semantics checker and ktlint to be formatting checker. Does detekt want to replace ktlint?

[Big Chungus]

Detekt doesn't replace ktlint. It just integrates with it. Under the hood same ktlint binary is downloaded and executed.

[Big Chungus]

Or did you mean some overlapping "style" rules that at the moment needs to be configured twice in detekt.yml?

[Jan Skrasek]

So my question was based on the changelog here:

[Jan Skrasek]

Now I've opened those PRs and it seems to "reregister those rules from Ktlint", so I'm now puzzled even more 😄

[Big Chungus]

Hmm, maybe they're trying to merge duplicated rules? I personally would love to have ktlint integrated into base detekt binary rather than being a plugin.

[gammax]

We wrap every new KtLint rule so that you can use it if you use detekt-formatting (the Ktlint wrapper).

[gammax]

If we would not do that, you won’t be able to execute those KtLint rules from Detekt.

[Jan Skrasek]

So detekt is kind of another ktlint-gradle plugin? I didn't know that at all! 🙂

[gammax]

kind of another ktlint-gradle plugin?

Essentially with Detekt you can create custom rules. We create a set of rules that internally are running KtLint and called this detekt-formattign as those are also the only rules that are effectively ‘formatting’ your code.

So yeah it’s a bit like a ktlint-gradle plugin

[Jan Skrasek]

Thank you for clearing this up for me :)