Will we ever see the v5?

[KillyMXI]

@TehShrike @RebeccaStevens

Sorry to be an another "still alive" question.

What happened in January so the work on the package is stopped since then?

My level of English doesn't allow me to disambiguate the answer in #224

I rely on customMerge behavior and can't seemingly migrate to lodash.mergeWith.

deepmerge-ts seems overcomplicated, and it might require unidiomatic boilerplate at best in order to reproduce "choose behavior by key" logic if I understood it correctly.

I'm at the point where I have to choose between

• keep using deepmerge in hope it will live on and get ES modules support for example;
• do my own merger from scratch (because I apparently have too much time and set to rewrite the world);
• fork deepmerge (perhaps from https://github.com/RebeccaStevens/fork-deepmerge/tree/lint) and do my own thing from there.

Fragmentation of the ecosystem is not nice, so I thought I'd ask here first.

[RebeccaStevens]

I'm keen to work on v5 and get it released by I haven't heard from @TehShrike for a while. I don't have push access to this repo as of yet so I can't really do anything myself.

With regard to deepmerge-ts, what is it that seems overcomplicated to you? If there is anything I can do to make things seem less complicated, I can make changes to improve things. Or I can just help with converting your current setup if you like. It would probably be best to open a new issue/discussion over there (rather than talking about it here).

[lipnitsk]

@macdja38 seems to have push access (see #235). Any comments?

[macdja38]

@lipnitsk @RebeccaStevens I reached out to @TehShrike on discord, now that Christmas is over we'll be taking a look at what we can do to help!

[TehShrike]

Is there a feature in v5 that you're waiting on?

When I allocate a weekend to deepmerge next, it will be with the goal of getting this library to a stable state where it is obvious that new features will not be added.

Like all the existing deep merge libraries, deepmerge is fundamentally flawed, and I would rather describe/link to the correct implementation than try to refactor this library with all its backwards compatibility for all the folks who currently depend on it.