It is currently possible for a published package to break a build without undergoing a major version number bump, if it uses exposing (..) and one of its dependencies adds something that causes a namespace conflict.
A given package can prevent itself from causing namespace conflicts like this by never using "exposing (..)" in its imports. I tried doing that for a library in a case where I would normally use "exposing (..)" for the elm-html DSLs, and it was surprisingly little extra effort: https://github.com/NoRedInk/elm-html-widgets/blob/master/src/Accordion.elm
Elm could turn this practice into a guarantee by enforcing a rule like "if you have exposed modules, you must document all your exposed functions and you cannot use exposing (..) in your imports."
It is currently possible for a published package to break a build without undergoing a major version number bump, if it uses
exposing (..)
and one of its dependencies adds something that causes a namespace conflict.A given package can prevent itself from causing namespace conflicts like this by never using "exposing (..)" in its imports. I tried doing that for a library in a case where I would normally use "exposing (..)" for the elm-html DSLs, and it was surprisingly little extra effort: https://github.com/NoRedInk/elm-html-widgets/blob/master/src/Accordion.elm
Elm could turn this practice into a guarantee by enforcing a rule like "if you have exposed modules, you must document all your exposed functions and you cannot use exposing (..) in your imports."
This was originally discussed on elm-dev, and discussion should continue there.