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.
lodash 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 packageA jscodeshift transform is available to convert per method package imports to main lodash package imports.