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

Open
@jfmengels

Description

@jfmengels

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions