Planning for 0.19 migration

[Noah]

Hello fellow maintainers of elm-community!

We are coming up to the time of the Elm lifecycle when we might want to start considering which repos to depreciate, upgrade, or drop.

This cycle is a bit different from the others, as now we have many more repositories than we previously did. Some of them may no longer have a place to fit in with the current ecosystem.

Deprecation

If you aren't familiar with how deprecation in Elm works, we generally just do not publish a package for a given version. Sometimes users will request a package to be upgraded, in which case it may be worth upgrading. In other cases, it may not be worth it -- entirely dependent on the repo.

Planned Deprecation

For sure, ones we do not intend to upgrade:

• elm-check

De-duplicating functions in *-extra

For our *-extra packages, we should aim to identify which functions now exist in core. This includes functions like List.Extra.andThen, which is now List.concatMap.

Deprecation or moving current packages

There are others that may be worth depreciating or passing to someone other than elm-community. The goal is for those packages to be re-thought as open problems without solutions.

One such example is undo-redo, which makes more sense to exist as an example repo instead of a package, suggesting to users who need this functionality to build it themselves.

[Evan Czaplicki]

Thanks for organizing this @eeue56!

I'll add the list of packages I felt should be considered for deprecation/moving:

easing-functions
elm-combine
elm-datepicker
elm-route
elm-webpack-loader
elm-webpack-starter
graph
intdict
lazy-list
material-icons
ratio
undo-redo
typed-svg

I created this list by going through this list and following my gut instinct about whether it "obviously makes sense" for them to be in the @elm-community org. In other words, these do not represent deeply held opinions!

I outlined some basic arguments in a couple cases:

• lazy-list will probably not be possible with 0.19 because I'd like to get rid of elm-lang/lazy
• typed-svg involves fairly significant design decisions and (without knowing the details) it seems like folks could come to pretty different conclusions
• easing-functions involves very particular design decisions on animation. I have been looking into springs personally, and I could see this overall problem going lots of different ways.

I also made some notes about how we can proceed with data structure packages like intdict and graph. Check them out in this document.

My guiding feeling here is having fewer packages of higher-quality is better and I feel that the ripple effect of dropping packages will be that folks feel more confident in working on certain problems and we'll end up with a stronger ecosystem overall.

Anyway, thanks again for getting this started @eeue56!

[Max Goldstein]

As the person who added easing-functions, I think we can deprecate it. Seems fine for it to be a personal (non-community) package.

[Noah]

In the case of lazy-list, I think we will update it to be the pure-Elm version that I created, as it's required for elm-test, and it performs better anyway. A focus will be made on laziness, not on memoization, which will be a breaking changes for most people. I'd rather not have elm-test depend on personal packages. But maybe we can just inline those packages

For the webpack packages, I'm reluctant to say yes or no without seeing the alpha -- regardless of how much the build system has improved, there will still be a need for a webpack plugin, and plugins are something you really don't want to write by hand.

[Eric Loren]

elm-datepicker here. Especially given the more impressive other datepicker I've seen out there, having a datepicker doesn't seem like a "standard lib" kind of thing, even for a UI focused lang (given how many ways one can make such a thing). Totally fine moving/deprecating.

[Max Goldstein]

Here's the plan for elm-test: elm-community/elm-test#191

[Marek Fajkus]

This issue is pretty old at this point. I wonder if there are some actions planned. It seems to me that elm-community overall is fading a bit which I find unfortunate. I think it would be valuable to have active organization maintaining hi-quality (and consistent) extensions for core.

I also agree that phasing some libraries outside of elm-community might be right move. Especially given how challenging it is to find long term maintainers.

as an example see #81

I think this situation would be far less problematic if this package lived outside of elm-community - that way every fork would be equal while by having stale fork in elm-community we don't really give people outside of it chance to build new main line version of library they depend on.