Hacker News Reader

Comment by SomeCallMeTim | Hacker News Reader

When I looked at pulling in a "micropackage" from Lodash it had so many dependencies that had dependencies (3-4 levels deep sometimes) that instead of being ~15-20 lines of JavaScript at most, it ended up being 300-400 lines, if I remember correctly.

Ended up writing my own mini-routine instead. If I ever need enough of Lodash to care I'll just import the whole thing, which is the only way to get lazy evaluation anyway.

View on HN

Lodash v4 reduced the deps of its individual modularized method packages.

It also offers modules inside the primary package now, e.g. require('lodash/chunk').

There's babel and webpack plugins to make cherry-picking and bundle size optimizations a breeze too.

https://github.com/lodash/babel-plugin-lodash

https://github.com/lodash/lodash-webpack-plugin

I've been using Rollup for bundle size optimizations, and I believe it will work with the lodash internal packages.

Neither Rollup nor Webpack 2 will tree-shake Lodash properly. The best option at the moment is babel-plugin-lodash.

Crap. I've already banished Babel from my toolchain -- the Babel ES6 shim throws a warning in Firefox about modifying the prototype of an object, and from what I can tell that will kill or limit both V8 and SpiderMonkey optimizations from that point on.

Back to plan A: Don't use Lodash in client code unless I'm willing to use the whole thing (so that I can get the chaining optimizations, which cherry picking doesn't support anyway).

There's no hard requirement for babel-polyfill or babel-runtime.

Babel works great without shims in modern enviros (I don't use shims in my projects).

Reply on news.ycombinator.com