Upgrade lodash to v4.17.5+

This is using lodash@2.x, which has a vulnerability: https://snyk.io/vuln/npm:lodash:20180130

I might revisit and PR this at some point later - dealing with other modules having the same problem in the meantime…

[spalger]

is there any kind of CI behind this somewhere out of the public eye?

Not at this time

Which versions of node/browser are supposed to be supported? I see most of the code is ES5?

As of version 14.0 esjs only supports node 4+. Also as of version 14.0 browser builds are not currently being transpiled, which means that they probably don’t have great browser support but that should be fixed by #645

what would your estimate of how long it would take for this lib?

Things I’m considering when estimating:

• I was pretty new to lodash when I first wrote this lib so I don’t expect much esoteric feature usage
• you are already familiar with the breaking changes that will need to be accounted for
• 558 uses of _. across 70 files using 80 different method, 25 of which are custom methods from src/utils.js (list of uses found)

Based on this I’d assume it would take at least a week or two to walk thought and verify each use and make sure that it’s going to work in the new version of lodash. That of course depends on how much time is in “a week”.

I know there’s issues getting integration tests to run… but is there a summary of what it takes to do it? Even if they’re flaky - they might still be useful…

The majority of the integration tests just verify that the client is exposing the elasticsearch rest api spec, which can be useful but I don’t feel it really stresses the parts of the lib that are actually at risk with an upgrade like this; I’m more concerned with things like connection pooling sniffing.

As I can’t get grunt coverage to run… what was the last known coverage? How much can I trust unit tests?

Last know coverage was 96%, but that was from two years ago. The core library hasn’t seen any major updates in that time, so the unit tests can’t be trusted completely, but it’s not in the worst shape. I could probably spend some time and get the coverage report working again. Here is the one from Feb 2016: https://coveralls.io/builds/5225485

What’s master branch for (14.x is the default…)?

A while ago I tried to make a bunch of improvements to the client, which I was doing in master, but I never finished them and ended up needing to divert attention elsewhere and subsequently release new versions of the client. So, master is mostly broken and I think be migrated to a “failed” branch of some sort for reference, then we could reset master to match 14.x… For all intents and purposes 14.x is the current master branch.

What’s your take on “unbundling” utils back into lodash and node util? (and whatever remains as utils)

I assume you mean not extending the lodash object with the utils? I’m 100% for that. I would never extend lodash with new methods like I did back then. I also would never use a library like lodash so extensively ever again, because the upgrade path when massive changes are made to the library is so rough when you use it everywhere. I’m much more keen to use small modules that can be independently upgraded, or just writing simple helpers that do the one thing I need from a lodash method.

[dman777]

With ES6, there should be no reason not to stay native to JS and avoid the extra bloat of libraries like lodash. Please remove lodash.