Compiler: Module name collision in generated code

[evancz]

As it is, each module is attached to Elm according to its name, so Search.View becomes Elm.Search.View.

This becomes problematic when there are many packages involved that may have modules with the same names. For example, if there's a private Utils module in evancz/focus and in evancz/automaton, the module that wins at runtime depends on what order things were compiled.

The solution is to use fully qualified names in generated code, so Utils would be Elm.evancz.focus.Utils or something like that.

[joaalto]

I just ran into a module name collision. I'm using rluiten/elm-date-extra in an hour reporting app I'm writing. Then I needed some UI components and decided to bring in Elm-UI. Unfortunately this doesn't work, as Elm-UI depends on mgold/elm-date-format, and both elm-date-format and elm-date-extra have a module called Date.Format:

I found multiple modules named 'Date.Format'.

Module 'Ui.DatePicker' is trying to import it.

Modules with that name were found in the following locations:

    package mgold/elm-date-format
    package rluiten/elm-date-extra

[evancz]

Whoo, resolved in 0.17!

[szagi3891]

how can use it?

[evancz]

To clarify, the initial issue was that if two packages have private modules with the same name, it used to cause problems. So if package tom/array had a Utils module that was not exposed, and if package sue/animation had a Utils module that was not exposed, it would mess up. That problem was fixed.

@joaalto posted about a separate issue, thinking this was tracking what he was worried about. That happens, and that is why I recommend always opening a new issue rather than piling on things that you think are your problem.