Prefer lodash functions over native JavaScript

Now that we are introducing lodash (https://github.com/eslint/eslint/pull/5015) it would make sense to prefer lodash over the native JavaScript methods.

lodash has been created to provide a consistent cross-environment tested collection of utility functions to work with arrays, objects and strings. It is one of the most popular NPM packages.

Since ESLint goal is not related to dealing with cross-environment inconsistencies, it would make sense to abstract library code using a well-adapted utility library. Some benefits:

• This would reduce the surface of the codebase.
• This would reduce the testing scope.
• This would make the code more consistent.
• Using eslint-plugin-lodash enables to further enforce code consistency.
• Using babel-plugin-lodash-modularize enables ES6 modularisation of the imports.
• This would reduce the learning-gap needed to contribute to the codebase (user does not need to be aware of node version support for specific ES features).

@jdalton might have more arguments to add.

[nzakas]

👎 As I mentioned on the PR, I don’t like this approach. I want to use the native methods when available and only use lodash for things that aren’t available natively.

[jdalton]

The only thing I’d add is that although lodash has methods like _.filter and _.map, which have ES5 flavors, it also has features, like iteratee shorthands to simplify code, that are missing from their ES5 counterparts.

_.map(objs, 'id');

instead of

objs.map(o=>(o!=null?o.id:void 0));

or

_.filter(objs, {'a':1,'b':{'c':2}});

instead of

objs.filter(o=>(o!=null&&o.a===1&&o.b!=null&&o.b.c===2));

In addition, methods like _.filter, _.map, _.slice, and others support lazy evaluation, shortcut fusion, when chaining without any additional work.

Once you start using lodash methods a bit more I’m sure places to cleanup ESLint will start to jump out.