Project idea: prefixed package generator

Request Feedback
1

The problem

@gampleman and I recently ran into an issue when trying to update the elm-visualization package to use elm-geometry version 3. The core problem is that elm-geometry now uses elm-units throughout its API, but both elm-visualization and elm-units include an exposed Force module (for force-directed layouts and force the physical quantity respectively).

Since elm-geometry uses elm-units types throughout its API, basically any code that depends on/uses elm-geometry directly also has to depend on/use elm-units directly. However, if elm-visualization depends on elm-units directly, then within the elm-visualization source code import Force is ambiguous - does it refer to the elm-units module or the elm-visualization module?

A potential solution

I’ve filed an issue to act as an additional data point to help figure out a long-term fix to the problem of ambiguous module names, but in the meantime it would be useful to have a short-term workaround. One possibility that @gampleman and I came up with was to create a ‘prefixed’ version of the elm-units package, that would depend on elm-units but expose its types and functions through prefixed modules. For example, such a package might have a Units.Force module that wraps the elm-units Force module:

module Units.Force exposing
    ( Force
    , Newtons
    , newtons
    , inNewtons
    , ...
    )

import Force

type alias Force =
    Force.Force

type alias Newtons =
    Force.Newtons

newtons : Float -> Force
newtons =
    Force.newtons

inNewtons : Force -> Float
inNewtons =
    Force.inNewtons

Then, elm-visualization could depend on this hypothetical elm-units-prefixed package and import Units.Force instead of Force. Since the Units.Force module doesn’t actually introduce any new types or functions, it should have negligible impact on generated code size and would allow elm-visualization to interop directly with other code that uses elm-units.

Call for help

It seems like it would be useful to have a tool that could generate prefixed packages like this. It should be reasonably straightforward to do so by using the elm/project-metadata-utils package to parse the docs.json file generated for elm-units and extract all public types and functions from that; there should be no need to parse the actual Elm source files, since by definition we’re only interested in the publicly-exposed types and functions! Some sort of (likely Node-based) CLI wrapper would then need to be written to read a docs.json file, give the contents to an Elm worker that would generate the wrapper module source code, and then take the results and write the actual .elm wrapper source files.

Is anyone interested in taking on such a project? I’m kind of tempted myself, but I think I should really be spending most of my open-source time finishing up elm-3d-scene and getting it ready to publish (it’s getting very close, but there’s still a fair bit of documentation work to do).

2 Likes
2

I think I can take this on, I’ve done a few bits working with Elm in tandem with node/fs so it shouldn’t be too difficult.

I’ll start experimenting while i’m procrastinating today…

2 Likes
3

That’s awesome @pd-andy, thanks so much! Definitely happy to discuss approaches/answer questions on Slack. Although now I feel a bit guilty distracting you from your own tireless efforts to answer other people’s questions on Slack =)

4

I also have that problem in some packages. It’s painful not to be able to load different Graphql modules for exemple (since every package related to the almost same thing need to have the same name, it’s even more challenging !)

5

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.