Lodash as first class citizen?

[kulmann]

Projects out there have the idea of banning lodash from their codebase. I personally don't see a reason other than the bundle size to get rid of lodash. But that's a tradeoff I'm willing to accept in order to not maintain (and test!) custom helpers in our codebase.

I'd like to propose the following:
1: native language features should always take precedence over lodash (example: no need to use e.g. sort or filter from lodash on arrays)
2: lodash should always take precedence over custom made helpers
3: if custom helpers are needed, we require them to have 100% unit test coverage

A good read regarding this topic certainly is https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore
Knowing that, my proposal still stays the same.

I'd like to hear opinions and then come to a decision.

[LukasHirt]

Even if we'd want to stay away from custom helpers, why use lodash directly? We still could use lodash-es for functions that we can get from there and if not, we can always grab for some specific NPM package that achieves our specific goal...

[fschade]

Fine using lodash :)

[pascalwengerter]

I'd also vote highly in favor of removing lodash and relying on single lodash-es imports as the second step of your 3-point decision plan

[kulmann]

I think a sufficient amount of time has passed. Decision is that we're going to use lodash-es instead of writing own helpers. This gives us the benefit of less code maintenance and having well tested helpers at the quite little cost of the dependency size.

[fschade]

as written above we decided to use lodash-es as a first class citizen.