A large utility library

[gampleman]

With the demise of elm-community, I have though that perhaps we could make another experiment in community maintenance. In this case, the idea is to make quite a large library that collects all the -extra libraries that pertain to elm/core.

There are a bunch of things that I'd like to happen:

• Find an invite additional maintainers. Perhaps some of those who were involved in these sort of projects before? (I'm somewhat hesitant to directly tag anyone at this early stage)
• Write an appropriate README.
• Collect credits for all original authors and maintainers, mention them in README and LICENSE if required
• Check licenses that they are suitably compatible.
• Go through string-extra and figure out if the code is salvageable wrt unicode issues. We can possibly drop this library in the initial release if it is too troublesome.
• Decide whether we want to be backwards compatible with the existing libraries. (see Renaming things, removing things #5)
  - On the one hand, being backwards compatible makes upgrading trivial.
  - On the other hand, some of the libraries have some fairly ridiculous functions that I'd like to drop (i.e. sliceUntil = slice 0 is in my opinion a function that isn't worth having, as it just obfuscates perfectly straightforward code).
• Review and add non elm-community libraries for the other types in elm/core.
• Elm-review now reports 62 errors. I can suppress these, but it would be good to actually address these issues.
• Go through the libraries and apply any sensible outstanding PRs (especially corectness/performance ones). I've already done some of this, but would be good to double check.

[supermario]

I think this is worth trying, and personally I'd happily use it on my projects especially given Elm doesn't make you pay the cost of a large package when you only need a few functions.

If you wanted to not be the "face" of the collection, I'd be happy to host the experiment under the elmcraft/core-extra namespace, but if you do want to be the "face", that would be even better 👍

That said – I'm not an -extra or fork-of--extra maintainer, so probably the opinion of those folks is more important.

[miniBill]

I'm leaning towards "reasonably backwards compatible". Ideally, we'd have an elm-review rule that can do stuff like sliceUntil -> slice 0.

One thing I'd love to see is more uniformity wrt the names ofcombineMap / traverse / sequence. I'd love to have a version "x.99" where we introduce X.Extra.uniformNames and then a x+1.0 where we remove the old names (again, ideally with an elm-review rule that makes migration automatic).

I think a core-extra library could be nice, especially because - as @supermario said - you don't pay the cost for unused functions, and the number of functions is not unreasonable anyway.

It would also solve the "maintainer MIA" problem. I would mildly prefer to host it in an org rather than under an individual name, mostly to avoid a left-pad if you ever want/need to change your username.

I'm going to create a google spreadsheet to analyze the existing APIs, so we can gather some feedback.

[miniBill]

This is the view link of the work in progress https://docs.google.com/spreadsheets/d/e/2PACX-1vQSY_O7Ukz-Q8JZjqRGh9EKM8skcngt83kC-Jgd1U32sCvBOH7IpF5pLCZJ_V5XI1rA8jtz-cMGeWS2/pubhtml
Contact me directly to get an editing link

[skyqrose]

Hi, I maintain https://github.com/elm-community/maybe-extra .

I think this is a nice idea that solves the governance and scaling problem of having separate maintainers for every repo. I agree some sort of centralized community organization would be good, so the package name looks more official, and to make it more durable / stable, which is important for a popular package. I get that that goes against the reasons for sunsetting elm-community, but I think that this package can do it better (less ambitious scope, a plan for maintenance, etc).

I'd be willing to be listed as a maintainer and pitch in a few hours every once in a while over the long term to handle incoming issues and such, but can't do much during this initial work to publish it. Once it's up and stable, I can deprecate maybe-extra and redirect people here.

One thing that I think is pretty important is that there aren't many updates over time. I don't think it'll be much of an issue, since this is collecting other libraries that are stable and well used. But I wouldn't want pointing people from maybe-extra to here to result in people getting lots of new dependabot pull requests for updates to functions they don't care about.

For backwards compatibility I think it's fine if there's some backwards incompatible changes, since switching to this library already requires attention and a manual change. As long as there's clear instructions (and drop in replacements) for anybody migrating. (Leaning heavily on "if it compiles, it works", of course.) There might be a couple functions in maybe-extra I'd take the chance to rename...

[gampleman]

W.r.t. gampleman vs elmcraft (as those seem to be the options on the table at the moment) I don't have much of an opinion. I'd be perfectly happy to host this under my name, but if others would be more comfortable with an org, I'm also totally on board with that. I'd suggest we continue work in this repo for the time being, and then arrange a migration with @supermario when ready to publish 1.0.0.

@miniBill thanks for the spreadsheet. I'm pretty much 100% on the general comments, I've also noticed those. W.r.t. the name uniformity, I think that makes sense with the more abstract names (i.e. combine, sequence and traverse all are basically meaningless, so we might as well pick some logical version and stick to it), but for instance concatMap is a better name in List than andThen. So, let's proceed on a case by case basis in that regard.

So far it seems like we're leaning towards making some breaking changes as long as they are reasonably mild (i.e. there is some compiler feedback and there is some reasonable alternative).

[Luftzig]

Great initiative and I would like to contribue even thought I am not an *-extra maintainer.

I do have one concern though, and this is around how the package would be built. would it be a single elm-core-extra package, or could I pick and choose like we have today? The latter is especially relevant if I want to use a different fork of some package, but not all.

[gampleman]

(We discussed this a bit in Elm slack but just to answer the question here)

The idea here is that this is a single monolithic library with minimal dependencies. Personally this is preferable to me, as I often would like an -extra function, but am often unwilling to add the extra dependency.

In general, the hope and ideal here is to have a relatively broad maintainer/contributor base and therefore minimise the need for forks or other libraries in the same space.

If this becomes somehow a real blocking problem, then there is always elm-package-prefixer to the rescue.

[ahankinson]

I have looked through the tests. It seems that the only ones that are failing are due to the toUpper core bug and the general bugginess of Unicode handling:

elm/core#1001
elm/core#1138

[gampleman]

@ahankinson could those be solved by adding the unicode aware version from elm/core#1138 to Char.Extra?

[ahankinson]

Oh, good point. I'll try that.

[ahankinson]

OK; no it won't work. The problem is in toUpper, which is Kernel code.

❯ elm repl
---- Elm 0.19.1 ----------------------------------------------------------------
Say :help for help and :exit to exit! More at <https://elm-lang.org/0.19.1/repl>
--------------------------------------------------------------------------------
> String.toUpper "ß"
"SS" : String
>

The PR only patches isUpper and isLower, and they rely on toUpper, as do the tests that are failing.

[ahankinson]

This probably even goes a bit deeper. In JavaScript:

> "ß".toUpperCase();
< 'SS'

Seems the "ß" character doesn't really exist in uppercase form. I found this Reddit thread that is helpful.

https://www.reddit.com/r/javascript/comments/9i455b/why_is_ßtouppercase_equal_to_ss/

🐇 🕳️

[miniBill]

It's even worse than that. If you look into elm-unicode you'll see that isUpper is actually a really nontrivial function if you want to support the full unicode range

[lydell]

If only Elm’s regex supported the u flag so we could use \p{Uppercase_Letter}…

[ahankinson]

elm/regex#17

Something for elm-janitor?