compiler icon indicating copy to clipboard operation
compiler copied to clipboard

Moving an opaque custom type and replacing it by an alias to the moved custom type is considered a breaking change

Open jfmengels opened this issue 5 years ago • 3 comments

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

module Exposed exposing (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
module NotExposed exposing (CustomType(..))

type CustomType = Constructor

----

module Exposed exposing (CustomType)

import NotExposed

type 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.

Version details

  • Elm: 0.19.1
  • Browser: NA
  • Operating System: Linux Ubuntu

Additional Details

I believe this issue can be batched with https://github.com/elm/compiler/issues/1978

jfmengels avatar Jun 21 '20 16:06 jfmengels

Thanks for reporting this! To set expectations:

  • Issues are reviewed in batches, so it can take some time to get a response.
  • Ask questions 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.

github-actions[bot] avatar Jun 21 '20 16:06 github-actions[bot]

Also happened when I changed a type alias into an opaque type

dullbananas avatar Jun 21 '20 16:06 dullbananas

Related / duplicate of https://github.com/elm/compiler/issues/1895

jfmengels avatar Dec 13 '22 08:12 jfmengels