Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternate way to configure consistent alias rule #35

Open
MartinSStewart opened this issue Oct 16, 2020 · 2 comments
Open

Alternate way to configure consistent alias rule #35

MartinSStewart opened this issue Oct 16, 2020 · 2 comments

Comments

@MartinSStewart
Copy link

MartinSStewart commented Oct 16, 2020

Currently the consistent alias rule takes a list of module names and the alias they should each use. What if instead the rule took a function with the type signature ModuleName -> Alias where Alias is

type Alias 
    = DontCare
    | AlwaysNoAlias
    | AlwaysAlias String

Edit: To elaborate on why this is useful, in the code we have at work, we have a lot of modules and I'd like to be able to do something like, all elm-ui modules shouldn't be aliased. Or all modules under Shared.* should use the last part of their module name as an alias.

@sparksp
Copy link
Owner

sparksp commented Oct 21, 2020

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants