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
Quick Summary: Moving an opaque custom type and replacing it by an alias to the moved custom type is considered a breaking change.
SSCCE
Imagine we have a published package exposing module Exposed
moduleExposedexposing (CustomType)
type CustomType=Constructor
and we then
Move CustomType to a non-exposed module NotExposed
Replace the CustomType in Exposed by an alias to NotExposed.CustomType
moduleNotExposedexposing (CustomType(..))
type CustomType=Constructor----moduleExposedexposing (CustomType)
importNotExposedtype alias CustomType=NotExposed.CustomType
This change is, according to elm diff and elm bump, considered to be a breaking change, even though it can't introduce compiler errors, as the type was opaque to begin with.
This can be a problem, because it turns some internal refactorings into breaking changes. In the context for which I am creating this issue, I am refactoring the jfmengels/elm-review package, and am trying to avoid breaking changes, as that will require all packages that use my package to be updated to the new version.
This behavior incentives package authors (or me at least) to turn custom types into aliases to internal custom types, just in case we need to do so later, to avoid unnecessary breaking changes.
Proposal
Make changing an opaque custom type into an alias to something a non-breaking change. I believe there are some cases where the change might result in a minor change, for instance when the aliased element is a record (meaning it can now be used as a function).
The other way around should also not be considered a breaking change, turning an alias to a custom type into the previously non-exposed custom type. If after that change the custom type is opaque, then this warrants a patch change. Otherwise, if it is not opaque, this should be a minor change, as we introduced the possibility to import and use the type's constructors.
Quick Summary: Moving an opaque custom type and replacing it by an alias to the moved custom type is considered a breaking change.
SSCCE
Imagine we have a published package exposing module
Exposed
and we then
CustomType
to a non-exposed moduleNotExposed
CustomType
inExposed
by an alias toNotExposed.CustomType
This change is, according to
elm diff
andelm bump
, considered to be a breaking change, even though it can't introduce compiler errors, as the type was opaque to begin with.This can be a problem, because it turns some internal refactorings into breaking changes. In the context for which I am creating this issue, I am refactoring the
jfmengels/elm-review
package, and am trying to avoid breaking changes, as that will require all packages that use my package to be updated to the new version.This behavior incentives package authors (or me at least) to turn custom types into aliases to internal custom types, just in case we need to do so later, to avoid unnecessary breaking changes.
Proposal
Make changing an opaque custom type into an alias to something a non-breaking change. I believe there are some cases where the change might result in a minor change, for instance when the aliased element is a record (meaning it can now be used as a function).
The other way around should also not be considered a breaking change, turning an alias to a custom type into the previously non-exposed custom type. If after that change the custom type is opaque, then this warrants a patch change. Otherwise, if it is not opaque, this should be a minor change, as we introduced the possibility to import and use the type's constructors.
Version details
Additional Details
I believe this issue can be batched with #1978
The text was updated successfully, but these errors were encountered: