Lodash is available in a variety of builds & module formats.
+ 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 package
+ A jscodeshift transform is available to convert per method package imports
+ to main lodash package imports.
+
+
+