Hey all. Is there some built in check to suggest replacing one class/function with another? This has...

# detekt

[dimsuz]

Hey all. Is there some built in check to suggest replacing one class/function with another? This has surfaced several times on different projects where classes can have same name, but different package (usually custom version of some class present in some library). In android's Jetpack Compose this will have its uses too, because google advocates using e.g. package my.project; fun TextField() rather than fun MyProjectTextField() to differtiate this from built-in anrdoidx.compose.material.TextField.

So I'm about to write some rule which detekts usages of com.google.TextField and suggests replacing it with my.project.TextField, same for classes. And I thought maybe I missed some existing rule.

[Brais Gabin]

What about ForbiddenImport?

[Brais Gabin]

Or ForbiddenImport with this implemented: https://github.com/detekt/detekt/issues/3501

[dimsuz]

yay, great, that will do! reason would be great too!

[dimsuz]

I may try to come up with the PR too!

[Brais Gabin]

The main point of that issue is to find a nice way to write the message in the yaml configuration. If you need any help with that issue just ask. I really would like that feature done 🙂

[dimsuz]

yep, ok. But it seems that the last message there had a consensus 🙂

[Brais Gabin]

That would be a starter but for me it will not close the issue. Buecase as you said it would be good to say for each import which one is the one that should be used instead.

[dimsuz]

Ah, right! I mixed your suggestin with the final comment, it's the other way around. I meant this:

ForbiddenImport:
    active: true
    imports:
      - import: 'org.mockito.*'
        reason: 'Use `com.nhaarman.mockitokotlin2` instead'
      - import: 'kotlinx.android.synthetic.*'
        reason: 'Use ViewBinding instead'

But perhaps this will be not as easy to implement as a global reason (for starters)

[dimsuz]

Though in my current project I would have already several different imports and reasons to specify here....

[Michael Marshall]

If you have control over the code you don't want to use, Kotlin's @Deprecated and ReplaceWith could help
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-deprecated/