Lodash 浓缩

Lodash 是个十分有用的工具库，但我们往往只需要其中的一小部分函数。这时，整个 lodash 库就显得十分庞大，我们需要减小 lodash 的体积。

cherry-pick 方法

Lodash 官方在 npm 上为每个方法维护了独立的包，便于我们直接引用。举个例子，如果我们需要lodash.chunk方法，可以直接安装lodash.chunk这个 npm 包，在代码中 import 即可：

1 2 3

import _chunk from 'lodash.chunk'; const result = _chunk(['a', 'b', 'c', 'd'], 2); console.log(result);

这样的弊端很明显，我们如果需要使用一个新方法，就要重新 install 一个新包并 require 进来。另外，每个包之间会有一部分重复（公共）方法会被重复打包，也会增大最终的打包体积。更好的解决办法，是直接从 lodash 完整库内导入方法：

1 2	import flatten from 'lodash/flatten'; import flatMap from 'lodash/flatMap';

由于 lodash 库中，每个方法都以独立模块封装，这样的引入方法，在 webpack 打包时，只会按需取指定的两个模块进行打包。从flatten 和 flatMap) 的代码可以看出，二者都用到了./.internal/baseFlatten.js这个模块，在 webpack 打包时，这个模块就变成了公共模块，这就避免了引入两个独立方法的包带来的重复。这种引入方式，官方叫做 “cherry-pick methods”，就像捡樱桃一样，捡自己需要的方法。

babel-plugin-lodash

然而，cherry-pick 方法的书写习惯，和我们平时使用第三方库的书写习惯并不一致。我们更习惯于直接 import 整个库：

1 2 3

import _ from 'lodash'; _.flatten([1, [2, 3], [4]]) _.flatMap([1, 2], n => [n, n])

这时，就是babel-plugin-lodash库发挥作用的时候。在 babel 编译代码时，这个插件可以自动把这种代码

1 2 3 4 5

import _ from 'lodash'; import { add } from 'lodash/fp'; const addOne = add(1); _.map([1, 2, 3], addOne);

转化为

1 2 3 4 5

import _add from 'lodash/fp/add'; import _map from 'lodash/map'; const addOne = _add(1); _map([1, 2, 3], addOne);

不过，这里有一些额外限制：必须要引入 babel（6以上版本）；必须要使用 ES2015 的方式引入包（即 import 的方式）。

lodash-webpack-plugin

在这一步的基础上，我们还可以使用 lodash-webpack-plugin 进一步减包。它的原理是将我们用到的方法（和间接用到的内部方法）使用更简单的方法替代。具体的方法对应关系，参照源代码中的mapping.js。使用方法也非常简单，只需要在 webpack 配置中引入该 plugin ，即可将所有的 cheery-pick 引入的方法自动进行转换。

需要注意的问题

一般介绍 lodash 打包优化的文章，介绍到这里就算结束了。但是，lodash-webpack-plugin 还有一系列的 feature 配置，它们的作用又是什么？实际上，经过 lodash-webpack-plugin 转化的 lodash 函数，已经和文档中对应的函数不完全等价，因此，如果我们用到了一些特定的特性，我们需要通过调整这些配置，保证我们的代码正常运行。

要关注这些配置的作用，只需要关注mapping.js这个文件，其中配置了features和overrides两个变量。features中每一项对应一个开关，每个开关则对应着若干组替换规则。以cloning为例，当对应配置关闭（默认即为关闭）时，插件将把内部的_._baseClone（暂且这样表示）方法替换为_.identity方法。而overrides变量中的每一项表示：只要我们引用了对应方法，则打开对应配置开关。

了解了这一点，我们再谈谈这个配置是怎样影响对应方法的。以_.sortBy方法为例，在它的源代码中（注：由于我们使用 npm 安装，因此需要查看 es 分支的源代码），我们可以看到它使用了四个内部库：

1 2 3 4

import baseFlatten from './_baseFlatten.js'; import baseOrderBy from './_baseOrderBy.js'; import baseRest from './_baseRest.js'; import isIterateeCall from './_isIterateeCall.js';

在flattening规则中，内部_baseFlatten将会被替换为_.head方法。本来根据_.sortBy文档，下列代码可以正常运行：

1 2 3 4 5 6 7 8

var users = [ { 'user': 'fred', 'age': 48 }, { 'user': 'barney', 'age': 36 }, { 'user': 'fred', 'age': 40 }, { 'user': 'barney', 'age': 34 } ]; _.sortBy(users, function(o) { return o.user; });

经过插件转化后，这种写法将会抛出异常。我们只能使用下列写法：

1	_.sortBy(users, [function(o) { return o.user; }]);

收到类似影响的函数还有_.overArgs,_.flow等几个方法。同理，_.get，_.has等方法，也会_baseGet方法被替换受到影响。

要解决这个问题，我们需要校验自己的代码中，有没有用到官方描述的Feature Sets中类似的特性，然后更改自己的代码，或者开启对应的特性配置。一般情况下，开启 flattening 和 paths 配置可以解决大部分问题。