d

    dimsuz

    8 months ago
    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.
    b

    Brais Gabin

    8 months ago
    What about
    ForbiddenImport
    ?
    Or
    ForbiddenImport
    with this implemented: https://github.com/detekt/detekt/issues/3501
    d

    dimsuz

    8 months ago
    yay, great, that will do! reason would be great too!
    I may try to come up with the PR too!
    b

    Brais Gabin

    8 months ago
    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 🙂
    d

    dimsuz

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

    Brais Gabin

    8 months ago
    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.
    d

    dimsuz

    8 months ago
    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)
    Though in my current project I would have already several different imports and reasons to specify here....
    Michael Marshall

    Michael Marshall

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