A process for core library fixes and improvements

Request Feedback
15

I wrote a spec for this before starting work on it, and this still reflects pretty well what I am trying to achieve in the first version - see the use cases listed at the bottom: Elm Package Server · GitHub

In the interests of being as uncontroversial as possible for the first release I also wrote:

  • Confirm the package does not contain ports.
  • Confirm the package does not contain kernel code.

I do also think, if I get to V1, that I would be interested in being able to publish patch releases to core packages. I have actually patched and produced a couple of PRs for core packages partly as I am intersted in exploring how this might work in practice. My process is to fork the package at its latest published tag, create an issue describing what is being fixed, linking to related issues in the core packages, and tracking its release status and make a clean patch. That is, to keep things as transparent and maintainable as possible, and to always feed back improvements to the upstream projects - whether or not they are ever accepted there.

I think great care needs to be taken when deciding what to patch. Anything that causes a runtime exception (apart from Debug.todo obviously) is fair game. Issues like this one - int parser fails on trailing decimal separator · Issue #14 · elm/parser · GitHub - I am not so sure about. If the patch never makes it back into Elm, then this introduces divergent behaviour in the alternative system, which could significantly affect program behaviour. There is also a simple workaround, to write your own int parser. So maybe some guidelines on what is suitable for patching need to be written up.

I don’t really see this as a fork of Elm, I would instead call it a release branch, where the Elm Janitor tidying up work goes. I have no desire at all to fork the language, its really a great language and I could not do better.

Some other related thoughts:

  • At some point beyond V1 I can imagine having a package repo that allows kernel code, this might be called the ‘unsafe’ repo. The domain tags concept in my spec would be very useful here as the ‘unsafe’ domain could be tagged and excluded (would be excluded by default, you would have to opt-in).

  • I have never yet run into a show-stopper bug in Elms core or compiler. Probably the closest example was the recent Safari for ... in bug, which I note Evan did get involved in the discussion of. As it affects more than just Elm, it seems like Safari should really own that one. The quality is generally very high.

  • I am interested in using Elm outside of web development because I think it has real potential as a cloud language. Also motiviation for the domain tags concept, since the browser domain is not needed there. This is analogous to the platforms concept in Roc that a few people have mentioned recently.

  • I like the name Eco, but not so keen on the ‘pro’ bit, although it does reflect my intention that it is for supporting professional work. Eco was already taken, so I had to add something to it, better suggestions very welcome.

2 Likes