Alternate way to configure consistent alias rule about elm-review-imports

[sparksp]

I completely agree with some type being a better way of configuring this - I had started making plans toward this when #15 didn't work out. Unfortunately I have lost all my notes on that so I need to flesh them out again.

One hold up is that I want to decide how to handle module shadowing. AlwaysAlias will happily handle importing Extras (as below), but @jfmengels and I would prefer not to allow any shadowing, which means needing a way to prevent the same module name or alias from being used (as in the above example).

-- NeverAlias
import Browser
-- AlwaysAlias "Browser"
import Browser.Extra as Browser

I do not think that DontCare is in the spirit of this rule. A module should either never be aliased or always aliased consistently - if you don't care then don't configure it and let the rule try to figure it out for you. The dream is that the rule needs as little configuration as possible and is able to tell from your code what 'consistent' is for your project. Configuring specific modules would then be most useful if you wanted to change an import and force the auto-fixes across the whole project.

[MartinSStewart]

I do not think that DontCare is in the spirit of this rule.

At work we've been using a very similar to this though it does allow for a DontCare choice. I think this is valuable when introducing this sort of rule to a team because it means you can incrementally restrict what import aliases to use. If we had to decide on how all imports would get aliased from the start the rule probably wouldn't be used.