Discussion: Allow multiple aliases? about elm-review-imports HOT 4 OPEN

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.)

from elm-review-imports.

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.

from elm-review-imports.

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.

from elm-review-imports.

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.

from elm-review-imports.