Hey everyone, Has anyone ever tried leveraging det...
# detekt
s
Hey everyone, Has anyone ever tried leveraging detekt for providing refactor scripts? Detekt easily gives me access to
KtElement
hierarchy. Making it quite easy to inspect and find certain usages, I was wondering if there was something like "auto-fix" like KtLint auto-formatting I can leverage as well. Otherwise, just finding certain usages and modifying the files is also an option 🤔
There is only this brief mention of it in the docs, but no samples. https://detekt.dev/docs/introduction/extensions/#autocorrect-property Does anyone know a blog, or video talking about it?
s
Semi-off-topic, but are you aware of https://github.com/openrewrite/rewrite? I believe it has Kotlin support by now.
Ah, no, it doesn't. https://github.com/openrewrite/rewrite/issues/21 was closed for other reasons.
s
I wasn't aware of that. Too bad it's been closed 😞
The corrections I need to make are quite simple, since most of the code is source compatible. What I'm looking to do right now is find certain usages, if found change an import
import arrow.core.continuations.effect
to
import arrow.core.raise.effect
and add an additional import. For example
import arrow.core.raise.fold
. That would solve 99% of the expected migration work from 1.x.x to 2.x.x in Arrow
b
I was recently looking at how to do this kind of things as well. Not sure about Detekt's auto-fix feature, but if it turns out it can't be used, for simple fixes, you could make a small app (or kts script maybe?) that uses
kotlin-compiler-embeddable
directly. For simple fixes (like the one you show above), it's not too hard to use - and you can get inspiration from the detekt source for how to setup things. As soon as you need to resolve types however it's getting complicated.
g
It's doable with Detekt (that's how out KtLint wrapper works). Sadly we don't have an official sample but we should make one :)
b
Can you create an issue to improve our documentation on that part? We already have some sample rules, we just need to add a new one showing that functionality.
s
We decided (with good reasoning) to not mess with user code as part of detekt's native rules. As @gammax mentioned, there's way to accomplish your @simon.vergauwen use case by leveraging the ktlint wrapper in detekt.
b
I agree that we should not mess with the code on our own rules. But we could have a sample about how to do it. On the ktlint wrappers you can't see the full path.