Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jfmengels opened this issue Jun 21, 2020 · 3 comments

Comments

@jfmengels
Copy link
Contributor

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 #1978

@github-actions
Copy link

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.

@dullbananas
Copy link

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

@jfmengels
Copy link
Contributor Author

Related / duplicate of #1895

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants