-
-
Notifications
You must be signed in to change notification settings - Fork 25
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
Remove support for «exposing (..)» from import statements #76
Comments
why not include |
Good question. I believe this was tested in Personally, I think
|
Someone was writing multiple independent tests at the
To your arguments:
The strongest argument I can see is your first one, which, as wolfadex pointed out, could be solved by treating exposing everything as a warning and an error in production/optimized mode just like |
|
To 2., of course I'd need deeper insight: What's the benefit of module Translation exposing (..)
picture =
{ de = "Bild", en = "picture", ... }
settings =
{ de = "Einstellungen", en = "settings", ... } vs for example module Translation exposing (for)
for =
{ picture =
{ de = "Bild", en = "picture", ... }
, settings =
{ de = "Einstellungen", en = "settings", ... }
} I guess something to do with types etc. which can't be replicated with Anyway, your examples seem like valid cases where |
In our particular case, we compile one app per language. So our translation files look like: module Translation exposing (..)
picture = "Bild"
settings = "Einstellungen"
... a lot more ... We then use a tool like linked-folder to symlink the correct translations before build. The benefit of not wrapping it all in a record is improved static analysis, dead-code elimination and a flatter namespace. Not saying this is the best way to do it, but it works very well for us. |
Agreed. |
No description provided.
The text was updated successfully, but these errors were encountered: