lydells post on the order in which things should be tackled establishes the right principal for ordering this work - which I call “conservative maintenance”. Maybe a better name for it is finding the path-of-least-disruption.
Fix the stuff that does not disrupt anyone first.
This is a good idea because its all going to be hard work whichever way it happens. If we can get to the point where we are able to fix a few things, in ways that does not exclude any existing user of Elm from adopting those fixes, we also would have proved that we can do this work together. If we can’t, other approaches are equally pointless.
Supporting that idea, is the reason I started cataloguing PRs and ordered them from least to most disruptive.
Yeah, I thought this would be easy, but I thought about it some more and realized its perhaps not so easy.
You could trick the existing Elm compiler into downloading
free/core 1.0.25 and thinking that it is
elm/core 1.0.5, but I don’t like that the version is essentially a lie. It would get put in the
ELM_HOME/0.19.1/packages/elm-core1.0.1 directory. Potentially someone could end up not knowing what version of what code they are really running in production, and this is never a good idea. Potentially people could get confused and repeatability of builds sacrificed.
Ideally I would like to be able for users to use bug fixed packages in a user friendly way, so without having to pin to a git hash using git sub-modules or something like that. With the same kind of semantic versioning that Elm already has. So I think maybe something like having bug-fixed packages never use the
elm/*, always their own namespace
free/* (or whatever your gonna call it…). When you use a
free/* package that can substitute for an
elm/* it needs to be done with semantic versioning, and in such a way that its very clear that the substitution is taking place - the substitute versions get added into
elm.json or some enhanced version of it, the build is repeatable, package tools report the actual used versions clearly, etc.
It occurs to me that
elm diff already implements semantic comparison of packages, so is available as a tool to construct the mapping between the substitutes and originals.
Looks likely though, that we can just do something with git submodules to get us started, then figure out how to make it nicer at a later time.