elm-lang / elm-package

Command line tool to share Elm libraries
BSD 3-Clause "New" or "Revised" License
213 stars 66 forks source link

Allow arbitrary aliases to count as 'exposing' types? #281

Open ianmackenzie opened 7 years ago

ianmackenzie commented 7 years ago

This is an example of some of my own code and how it might interact with to the suggestion in #277 (which I agree with in general); I currently have a setup like the following:

-- Internal.elm: non-exposed module

module Internal exposing (..)

type Point2d
    = Point2d ( Float, Float )

type Axis2d
    = Axis2d { originPoint : Point2d, direction : Direction2d }

-- Axis2d.elm

module Axis2d exposing (Axis2d, with)

import Point2d exposing (Point2d)
import Internal

type alias Axis2d =
    Internal.Axis2d

with : { originPoint : Point2d, direction : Direction2d } -> Axis2d
with =
    Internal.Axis2d

-- Point2d.elm

module Point2d exposing (Point2d, mirrorAcross)

import Internal exposing (Axis2d)

type alias Point2d =
    Internal.Point2d

mirrorAcross : Axis2d -> Point2d -> Point2d
mirrorAcross axis point =
    ...

So the Axis2d module simply imports the Point2d module and the alias defined there (which is the canonical, public Point2d type), but to avoid a circular import the Point2d module simply refers directly to the non-exposed Internal.Axis2d type instead of the alias in the Axis2d module. So all the necessary types are exposed through some module, but may be referred to using different aliases in different modules. Ideally I'd like "types used in publicly exposed functions must themselves be publicly exposed" to be interpreted as "those types must be exposed via some alias in some module in the package".

process-bot commented 7 years ago

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.