Lodash methods are available in standalone per method packages
like lodash.mapvalues, lodash.pickby, etc.
These packages contain only the code the method depends on.
However, use of these packages is discouraged and they will be removed in v5.
Although they may seem more lightweight, they will usually increase the size of
node_modules and webpack/rollup bundles in a project that
transitively depends on multiple per method packages and/or the main
lodash package. Whereas many methods in the main
lodash package share code, the per method packages internally
bundle copies of any code they depend on.
For example, throttle uses debounce internally.
In a project using both methods from the main lodash package,
throttle will import the same debounce module as
any code that imports debounce directly, so only one copy of
debounce will wind up in a webpack bundle.
On the other hand, if a project imports throttle from
lodash.throttle, the extra copy of the debounce
code internally bundled into lodash.throttle will wind
up in the webpack bundle, in addition to debounce from the main
lodash package or lodash.debounce.
Lodashlodash isn't lightweight enough!
Don't worry—if you import or require methods
directly, e.g. const throttle = require('lodash/throttle'), only
the subset of lodash code your package uses will be bundled
in projects that use your package.
If importing this way seems cumbersome, you can use
babel-plugin-lodash
to transform named top-level imports like
import { throttle, debounce } from 'lodash' into direct import statements.
Furthermore, modern tree-shaking bundlers like webpack and rollup can avoid bundling code you don't need even if you don't use direct imports or the babel plugin.
lodash package
A jscodeshift transform is available to convert per method package imports
to main lodash package imports.