Discussion: Allow multiple aliases?

[Janiczek]

At GlobalWebIndex we have our own custom ConsistentImports rule.

It allows multiple aliases (we need this because of us having a convention import List.Extra as List, and Html.Attributes.Extra.autocomplete colliding with Html.Attributes.autocomplete, which makes us need to import the Extra as Attrs_ instead of Attrs in the modules that use the autocomplete value) - described more in the Elm Slack discussion.

We wanted to publish our rule, then found out this package exists, so we'd love to not divide the ecosystem.
Would you consider allowing multiple aliases for a given imported module in elm-review-imports?

[sparksp]

Sure thing. The rule would currently ignore Html.Attributes.Extra not using its preferred alias because of the collisions with other configured aliases - but that does mean it wouldn't enforce any alternative, any would be allowed. I can see this would be useful, but there's a few situations that I want to understand to make sure I get this right for you. Assuming the following config...

config =
    [ NoInconsistentAliases.config
        [ ( "Html.Attributes", "Attrs", [] )
        , ( "Gwi.Html.Attributes", "Attrs", [] )
        , ( "Html.Attributes.Extra", "Attrs", [ "Attrs_" ] )
        ]
        |> NoInconsistentAliases.rule
    ]

1. If you import Html.Attributes.Extra as Attrs_ but nothing else is imported as Attrs would you expect the rule to report that you should use Attrs, or say nothing because it's one of your configured aliases?
2. Would you expect Gwi.Html.Attributes MUST be aliased as Attrs (if it's aliased) even if another module is using the Attrs alias?
3. Does your answer to (2) change if the other Attrs module isn't in your config?
4. Would you expect import Html.Attributes.Extra as Attrs to be reported if something else is also aliased to Attrs (because there's another alias it could use)? Or would it be ignored because it's using one of it's allowed aliases?

(4) comes up for me when I use Svg.Attributes alongside Html.Attributes - on their own I like them to be aliased as Attr but when they're together I would prefer to alias Svg.Attributes as SvgAttr.

[Janiczek]

My expectations are:

1. It would be nice to report that we should use Attrs. (This is something our rule doesn't do, if yours does it that's way cool!)
2. Most likely yes. If we found another conflict, we'd add another allowed alias and tweak that way. I guess this has some overlap with (4)...
3. Probably not. But it's hard for me to imagine a scenario like that. Ideally we'd have all such aliases written out in the rule config.
4. Yes, that would be nice. (Again, our rule doesn't do that but it's a nice to have. Also, your note about (4) makes sense to me and I agree with it.)

[sparksp]

Thanks for your answers - I think they align with how I saw this going. The rule currently avoids or ignores conflicts so I need to change the logic a bit to force aliases that are configured, that'll probably simplify things for me overall.

[sparksp]

I've made some good progress over at #31 however I realised as I was writing up the PR that the imports are checked in module alphabetical order and you might have some other ordering in mind (e.g., config). This will require some reorganising/rethinking of the final evaluation but shouldn't be impossible.