You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 23, 2018. It is now read-only.
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.
The text was updated successfully, but these errors were encountered: