When two packages use the same Module.Name, neither can be used.

[ghost]

Quick Summary: When two packages use the same Module.Name, the last added via elm install can't be used

Reference: #1625

• Elm: 0.19.1

Packages

• elm-community/json-extra
• waratuman/json-extra

SSCCE

module Data.HttpDataAppletArtifact exposing (jsonDecodeAppletArtifact)

import Json.Decode exposing (Decoder, decodeString, field, int, string, succeed)
import Json.Decode.Extra exposing (andMap)
import Model exposing (AppletArtifact)

jsonDecodeAppletArtifact : String -> Result Json.Decode.Error AppletArtifact
jsonDecodeAppletArtifact jsonData =
    decodeString appletEntryDecoder jsonData

appletEntryDecoder : Decoder AppletArtifact
appletEntryDecoder =
    succeed AppletArtifact
        |> andMap (field "id" int)
        |> andMap (field "filename" string)
        |> andMap (field "code" string)
        |> andMap (field "size" int)
        |> andMap (field "created_at" int)
        |> andMap (field "updated_at" int)

Compiler output

Detected problems in 2 modules.
-- AMBIGUOUS IMPORT ------------------------------- src/Data/HttpDataApplets.elm

You are trying to import a `Json.Decode.Extra` module:

4| import Json.Decode.Extra exposing (andMap)
          ^^^^^^^^^^^^^^^^^
But multiple packages in your "dependencies" that expose a module that name:

    waratuman/json-extra
    elm-community/json-extra                                                                                                       

There is no way to disambiguate in cases like this right now. Of the known name
clashes, they are usually for packages with similar purposes, so the current
recommendation is to pick just one of them.

Note: It seems possible to resolve this with new syntax in imports, but that is
more complicated than it sounds. Right now, our module names are tied to GitHub
repos, but we may want to get rid of that dependency for a variety of reasons.
That would in turn have implications for our package infrastructure, hosting
costs, and possibly on how package names are specified. The particular syntax
chosen seems like it would interact with all these factors in ways that are
difficult to predict, potentially leading to harder problems later on. So more
design work and planning is needed on these topics.

                                                     Data.HttpDataApplets  ↑    
====o======================================================================o====                                                   
    ↓  Data.HttpDataAppletArtifact                                                                                                 

-- AMBIGUOUS IMPORT ------------------------ src/Data/HttpDataAppletArtifact.elm

You are trying to import a `Json.Decode.Extra` module:

4| import Json.Decode.Extra exposing (andMap)
          ^^^^^^^^^^^^^^^^^
But multiple packages in your "dependencies" that expose a module that name:

    waratuman/json-extra
    elm-community/json-extra                                                                                                       

There is no way to disambiguate in cases like this right now. Of the known name
clashes, they are usually for packages with similar purposes, so the current
recommendation is to pick just one of them.

Note: It seems possible to resolve this with new syntax in imports, but that is
more complicated than it sounds. Right now, our module names are tied to GitHub
repos, but we may want to get rid of that dependency for a variety of reasons.
That would in turn have implications for our package infrastructure, hosting
costs, and possibly on how package names are specified. The particular syntax
chosen seems like it would interact with all these factors in ways that are
difficult to predict, potentially leading to harder problems later on. So more
design work and planning is needed on these topics.

[github-actions[bot]]

Thanks for reporting this! To set expectations:

• Issues are reviewed in batches, so it can take some time to get a response.
• Ask questions in a community forum. You will get an answer quicker that way!
• If you experience something similar, open a new issue. We like duplicates.

Finally, please be patient with the core team. They are trying their best with limited resources.