The Big Kahuna: Underscore + Lodash Merge Thread

[jashkenas]

Dear Everyone,

JDD got in touch with me over email this morning, inquiring about the possibility of merging Underscore and Lodash together. I think it's high time to talk about the possibility again.

Some initial points for discussion:

• The Name: "Lodash" is very cute, but keeping "Underscore" makes the most sense, both for historical and _ variable reasons. Because npm doesn't allow name redirects (AFAIK), the merged project would be available as a module under both names for the foreseeable future.
• Lodash is currently > 12k lines of code, and Underscore is 1.5k. I understand that part of that is JSDoc noise, but it still seems potentially problematic and worth talking about.
• Documentation style. Ideally I'd like the Underscore docs to be written even more conversationally than they are at the moment.
• We should keep nicely annotated source code as a priority.
• And then the actual main work — I'm not familiar with the Lodash codebase. What parts of it do folks have objections to merging? What might not fit in well within a merged Underscore umbrella? Anything? Maybe not?

Edits in response to comments below:

• Strict(er) SemVer. Totally fine with me. I'm still of the opinion that true believer SemVer isn't something that actually exists in the real world (most changes are subtly backwards-incompatible in minor ways), but I have no problem praying to this golden cow to keep the philistines happy ;)
• "Governance Model": I don't think we need anything fancy here. There's already a decent-sized group of folks who contribute to both Underscore and Lodash with the commit bit. They can keep it. I do think we'd need a clear mission statement about the spirit of what the library should be. Utility libraries have a tendency to grow to include the kitchen sink, and the more we can successfully keep things focused, the better.
• _(obj) wrapper chains lazily by default. (Breaking change). Sounds fine to me.
• How does Underscore-Contrib fit in to all this?
• Folks. Please STOP +1-ing, 👍 -ing and meme-ing GitHub tickets. We get it, but it makes tickets hard to have conversations on. Contribute with something substantive instead.

Although it would be nice to keep the bulk of the discussion here ... there's also a Contributors-only cross-thread here: #2184

[jdalton]

Before digging into the discussion I just wanted to say 👍 and thank you to Jeremy for hosting and being open to discussions.

Sidenote: For those interested there's also a fair amount of chatter on twitter on the merge.

[tyscorp]

Does that mean lodash will no longer follow semver?

[jamesplease]

For future commenters: many of you will 👍 to this. If that's all you've got to say, it might be best to not add noise to the conversation. There's quite a bit to be discussed before this could ever happen, and it seems like this issue is attempting to be the forum for that discussion. If you want to stay involved, click the "Subscribe" button to the right to see notifications.

[phpnode]

Does that mean lodash will no longer follow semver?

@tyscorp I'm going to go ahead and say no, that won't happen

[lennym]

Firstly 👍

Now in actual response to a few of the points raised (disclaimer - I am a lot more familiar with underscore than lodash):

Call it underscore or something completely new. Lodash is obviously a take on underscore, and doesn't make a lot of sense on its own.

Things I would like to see from lodash in underscore:

Code split by category/method like var chunk = require('lodash/array/chunk'); in the lodash readme. I think this could go some way to mitigating the fact that lodash is much larger code-wise.

_.get - I find this absurdly useful, and it's basically the reason I started installing lodash instead of underscore.

Probably more to come as I think of things...

[Ky6uk]

Lodash is currently > 12k lines of code, and Underscore is 1.5k.

How about comparing only existing functions in both of __? Ofc we can make a custom build of lodash if 12k is our problem.

[JasonGhent]

"Lodash is currently > 12k lines of code, and Underscore is 1.5k. I understand that part of that is JSDoc noise, but it still seems potentially problematic and worth talking about."

Can we categorize what else contributes to the size differential?

[tdd]

Hey all,

I obviously 👍 this to death. Thanks @jashkenas for re-opening this, let's hope it's not a can of worms anymore.

A couple notes off the top of my head.

One thing from Lo-Dash I'd love to see happen in Underscore is the code split (that you find as multiple modules in the amp.js ecosystem) and general build/tooling that lets us not bundle the whole code when browerify'ing / webpacking / brunching / etc. a small lib of ours that only uses a couple _.xxx methods.

I wasn't aware of LoDash's _.get, which is admittedly kinda sweet.

Underscore would also need to be way more open about the iteratee thing, and use both situations (callback vs. prop name) in its code/usage examples, to drive the point home. It's great that it took this page from LoDash's book, but perusing the docs, it's almost completely hidden. It only shows up once and then is never illustrated again. This makes for way shorter code, though, and ties neatly with _.result, too.

Let's move this forward!

[zacechola]

The Name: "Lodash" is cute, but keeping "Underscore" makes the most sense, both for historical and _ variable reasons.

I hear iojs may be back on the market. 😜 But seriously, either name is fine by me.

Lodash is currently > 12k lines of code, and Underscore is 1.5k. I understand that part of that is JSDoc noise, but it still seems potentially problematic and worth talking about.

As has been pointed out already in this thread by @Ky6uk, there needs to be an apples to apples function comparison here.

Documentation style. Ideally I'd like the Underscore docs to be written even more conversationally than they are at the moment.

👍

We should keep nicely annotated source code as a priority.

👍

And then the actual main work — I'm not familiar with the Lodash codebase. What parts of it do folks have objections to merging? What might not fit in well within a merged Underscore umbrella? Anything? Maybe not?

Versioning needs to be clarified for sure and I also would personally appreciate the modularization that @tdd brought up as a nice to have.

[wraithgar]

The only pain point we've noticed using lodash is that in some packages that have several modules, each with quite a few lodash dependencies under them and in their dependencies, npm dedupe has a lot of trouble and often silently exits while trying to run. This is of course not currently a problem with things using underscore because it's one single module, and is something worth at least mentioning if you're talking about a transition to the lodash individual module approach.

[aredridel]

npm 3 will help the dedupe process immensely.

[glesperance]

Would be great if the merge could keep using semantic versioning as in lodash

[kud]

To be honest, I was already afraid with nodejs / iojs dilemma but glad they'll merge too. So I couldn't be agree more to see your projects merge too.

Congratulations anyway to you, you make a really good work.

(warning: I mostly use lodash for the moment on all my projects)

+1 for "underscore" because history + this is what I say when I read it.

+1 for the underscore's doc, clearer/cleaner in my opinion.

[xcoderzach]

I'm a huge fan of how lodash does lazy evaluation chains by default, rather than explicitly needing to call .chain(). Ideally that would be the standard going forward.