4 ms·
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
by SomeCallMeTim 10y ago
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.
- jdd 10y agoLodash 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/babel-plugin-lodash https://github.com/lodash/lodash-webpack-plugin https://github.com/lodash/lodash-webpack-plugin
- SomeCallMeTim 10y agoI've been using Rollup for bundle size optimizations, and I believe it will work with the lodash internal packages.
- jdd 10y agoNeither Rollup nor Webpack 2 will tree-shake Lodash properly. The best option at the moment is babel-plugin-lodash.
- SomeCallMeTim 10y agoCrap. 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).
- jdd 10y agoThere'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).