Removing prefixes from module names

Request Feedback
1

In my opensolid/geometry package, I have an OpenSolid. prefix on each package name which I included to avoid potential conflicts with modules from other packages. I’m considering removing the prefixes, but this would be a breaking change and could lead to import conflicts in the future so I wanted to get some feedback from the community first!

The main advantages I see of removing the prefixes are:

  • Consistency with other packages: elm-community/elm-test uses top-level Expect, Fuzz and Test modules, mdgriffith/style-elements uses top-level Style and Element modules, terezka/elm-plot uses a top-level Plot module, etc.
  • Less typing (the number of times I’ve typed import OpenSolid.Point3d as Point3d…), especially in the REPL where you can’t rely on autocompletion
  • Smoother integration with editors/IDEs that are optimized for unprefixed module names
  • More data points for this issue if import conflicts do arise

The main disadvantages:

  • Potential for conflicts: if I publish a plain Point3d module, then nobody using opensolid/geometry can use any other package which also exposes a plain Point3d module (they also can’t define their own Point3d module, but that’s a bit less of an issue)
  • Less clarity about imports: in the same way that seeing List.map in your code shows that you’re using a function from the List module, seeing OpenSolid.Point3d in your imports hints that you’re using a module from an opensolid/* package

If I do go ahead with removing the prefixes, I might also rename the Scalar and Interval modules to Scalar1d and Interval1d so that all top-level modules have a 1d, 2d or 3d suffix (which I think should be enough to avoid conflicts with any existing published packages, and reduce the likelihood of conflicts in the future).

Thoughts? Any alternate approaches I’ve missed?

4 Likes
2

Interesting. I might do the same with elm-visualization. Ideally the problem of conflicts should be solved on the language level. I guess as a mitigation for now, one could publish two packages:

  1. The first would be the real package with unprefixed modules.
  2. The second would be called something like elm-X-prefixed, and would simply depend on the first package and re-export everything from the first except the module names would be prefixed. This would be fairly annoying to keep up to date, but could probably be automated quite easily.

Then one would depend on package 1 until they encountered a conflict, at which point they could quite easily switch to the prefixed version.

1 Like