[fluxsauce]

I introduced this to our team and after a few months I have mixed feelings. Practically, it's a micro-optimization.

Lodash is convenient, consistent, well-documented, readable, and maintainable. Yes, there's some pretty needlessly redundant methods (isNull for example), but it provides a nice API to do it. The trade-off of a few microseconds is worth it.

Omitting lodash from your entire codebase is not going to magically fix all your problems; there are much more important things you can be doing with your time, such as delivering features or eliminating technical debt.

To reduce the amount you're requiring, you can just get a specific method like require('lodash/omit'). If overhead is a concern, that helps mitigate it.

We have set it to warn, not to error; it's good to raise awareness that you're doing something that has a potential performance cost, but for things like omit the recommended native alternative just isn't worth it.

What I do find it useful for is small projects (like a lambda function) where micro-optimizations DO count.

[davnicwil]

I agree with this. I think using lodash is a 'use boring stuff' decision in javascript. It feels kind of clunky and outdated in some ways, when new native APIs are covering more and more of what it can do year by year, but at the same time it 'just works' in the most obvious way possible.

With native APIs, you're essentially just doing the same things with a slightly different syntax and sure, it feels cleaner. It is cleaner - where those native APIs actually exist. But if you have to support anything but the latest versions of evergreen browsers, now you're worrying about polyfills, build targets, etc etc.

It's not that hard, but it's just one more thing to worry about and one more thing to be surprised by when it fails on a corner case in production. Meanwhile, if you'd just used boring old lodash, it would be working and you could be paying attention to something more important.