前言

webpack 是什么? 可以用来吃的吗？那么这篇文章可能并不适合你。

历史背景

随着 webapp 的复杂程度不断地增加，同时 node 社区的崛起也让前端在除了浏览器之外各方面予以强力衍生与渗透，不得不承认目前的前端开发已然是一个庞大和复杂的体系，慢慢的前端工程化这个概念开始逐渐被强调和重视。

在支付宝，前端工程化应该是先驱者，我们有一套配套工具和脚手架来交代项目的初始，调试与打包；有成熟的线上部署和迭代系统交代每一行代码的始与终；有智能化的监控系统来交代代码的优与劣。

如上这么做好处是显然的，让所有的事情变得可控与规范，但前端开发的灵活与便捷性却带来不少影响，代码不管是否本地经过验证，要发布必须重新全量构建整个项目，而有些同学的把预发调试当成和本地调试一样使用，先不提这种做法是否正确但衍生而来的问题是用户必须忍受每次全量构建的时长，另外也由于项目复杂的增大，通常一个中型的项目业务模块都会有上百个，加上应用架构所包含的内容，已经是一个不小的体量，即使进行单次构建，也可能让开发者足足等上几分钟，甚至几十分钟。

本文的重点就是想要让开发者尽量缩小带薪的痛苦等待。

受益群体

想知道 webpack 优化技巧，想要提升构建速度。

数据报备

本机硬件环境:

2 GHz Intel Core i7 / 4 核
8 GB 1600 MHz DDR3

项目数据:

457 个项目文件，项目依赖 40 个

运行数据:

在 node@4 npm3 下整个全量构建耗时达 192s

时间都去哪儿了

在埋头开始优化前，首先我们必须理清楚知道一次全量构建他所包含的时间分别由什么组成，这可能让我们更加全面的去评估一个问题。

T总 = T下载依赖 + Twebpack

Twebpack = Tloaders + Tplugins

在如上粗略的评估中我们可以把时间归结在两大部分，一个是下载依赖耗时，还有一个是 webpack 构建耗时，而这一部分耗时可能包含了各类 loader 和 plugin 的耗时，css-loader ? babel-loader ? UglifyJsPlugin ？现在我们并不清楚。

如何做

基于如上的评估我们大概可以从四大方面来着手处理

• 从环境着手，提升下载依赖速度；
• 从项目自身着手，代码组织是否合理，依赖使用是否合理，反面提升效率；
• 从 webpack 自身优化手段着手，优化配置，提升 webpack 效率；
• 从 webpack 可能存在的不足着手，优化不足，进一步提升效率。

从环境出发

一般碰到问题我们最容易想到的是升级一下依赖，把涉及构建的工具在 break change 版本之前都升级到最新，往往能带来意向不到的收益，这和机器出现问题重启往往能解决有异曲同工之处。

而事实上，也确实如此，在该项目中升级项目构建模块后提升了 10s 左右，暂时先不提其中的原由。

另外不得不吐槽 npm3 中安装依赖实在是龟速，那如何压榨安装依赖所需要的时间呢，是否有方案？或许大家已经听到过 pnpm，这里需要介绍下更为好用和极速的 npminstall。

先来看看项目在不同版本的 npm 以及在 npmintall 场景下的差异：

[email protected] | tnpm@2 (npm2)

修正后共计耗时 284s

依赖安装时长 182s

构建时长 Time: 102768ms 约为 102s

node@4 | tnpm@3 (npm3)

共计耗时 192s

依赖安装时长 64s

初始构建所需 Time: 128027ms 约为 128s

[email protected] | tnpm@4 (npminstall)

共计耗时 140s

依赖安装时长 15s

初始构建所需 Time: 125271ms 约为 125s

使用 tnpm@4/npminstall 能够达到立竿见影的效果，优化幅度达 70% - 90%

司内

npm install -g tnpm@4 --registry=http://registry.npm.alibaba-inc.com

司外

npm install npminstall --g
npminstall 

从项目自身出发

在未压缩的情况下脚本大于 1MB 变得非常普遍，甚者达到 3-4MB，这到底是因为什么？！

在这个过程中我分析了项目中的依赖，以及代码使用的状况。有几个案例非常的普遍。

案例一: 依赖与依赖从属不明确

在 package.json 中

"lodash": "^4.13.1",
"lodash.clonedeep": "^3.0.2",

在这个案例中根据需求只需要保留其一即可

案例二: 废弃依赖没有及时删除

很多时候我们业务变更很快，人员变动也很快，多人协同，这在项目中很容易被窥探出来

import xx from 'xxx';

然后在业务实现中并没有使用 xx

必须及时删除已经停止使用的相关库，无论是 deps 还是 devdeps，都使用 uninstall 的方式把相关依赖从 package.json 中移除，并千万记得也从源码中移除相关依赖。

案例三: 为了实现小功能而引用大型 lib

webpack 强大的混淆能力，让 web 开发 和 node 开发的界线变得模糊，依赖的滥用问题异常凸显。

moment(key).format('YYYY-MM-DD HH:mm:ss')
// 只是使用了 moment 的format 何必引入 moment
// 如果不想简单实现就可以使用更为专一的库来实现
// https://github.com/taylorhakes/fecha Lightweight date formatting and parsing (~2KB). Meant to replace parsing and formatting functionality of moment.js.


import isequal from 'lodash/isequal'
// 这样会导致整个 lodash 都被打入到包内
// 为何不直接使用
// import isequal from 'lodash.isequal'

等等等等。

引入一个第三方 lib 的时候，请再三思量，问自己是否有必要，是否能简单实现，是否可以有更优的 lib 选择

案例四: 忽略三方库的优化插件

这个项目是使用 antd-init 脚手架工具初始化而来的项目，所以在构建工具层面使用了 ant-tool/atool-build. 对于已经熟悉 ant-design 的同学而言，以上这些应该都已熟悉。

在查阅项目代码时候碰到了又一个很典型的案例

在 webpack.config.js 中引用了优化引用的插件 babel-plugin-antd

webpackConfig.babel.plugins.push(['antd', {
  style: 'css',
}]);

该插件会在 babel 语法解析层面对引用关系梳理即用什么的组件就只会引用什么样组件的代码以及样式。

// import js and css modularly, parsed by babel-plugin-antd
import { DatePicker } from 'antd';

但是很让人忧心的是我们很容易在原始代码里面找到这样的踪迹

import 'antd/lib/index.css';

一个错用可能就会让包的体积大上一个量级。

如上这类优化插件比如在 babel-plugin-lodash 中也有相关实现。

如果三方库有提供优化类插件，那么请合理的使用这类插件，此外之后 atool-build 也会升级到 webpack2，在 webpack2 中已经支持 tree-shaking 特性，那么如上优化插件可能就并不需要了。

案例五：babel-runtime 和 babel-polyfill

由于历史的原因 babel@5 到 babel@6，polyfill 推荐的形式也并不一样。但是在项目中我们可以发现一点是，开发人员并不清楚这其中的原委。以至于代码中我们经常可以看到的一种情形是以下两种方式共存：

//js文件
require('babel-pollyfill');

"dependencies": {
  "babel-runtime": "*"
},
"devDependencies": {
  "babel-plugin-transform-runtime": "*"
},
"babel": {
  "presets": [
    "es2015",
    "stage-0"
  ],
  "plugins": [
    "add-module-exports",
    "transform-runtime"
  ]
}

两种方式只需要一种即可，更加推荐下一种方式，在压缩的情况下至少能给代码减少 50KB 的体积

案例六：css-module

在 atool-build 中默认会对 *.module.less 和 *.module.css 的文件使用 css-module 来处理

atool-build 关于 css-module

而 css-module 这一块的处理由 css-loader 完成。css-loader 关于 css-module

对 css-module 还不清楚的同学可以移步至 阮一峰老师的 blog

简单来说使用 css-module 后可以保证某个组件的样式，不会影响到其他组件

在日常中经常有同学会跑过来问，为什么我的样式变成有 hash 后缀了，为什么构建文件变大了，原因就在于此。

如果你的项目使用 ant-design， 并且通过 antd-init 脚手架来生成项目，那么你所有的 less 文件都会被应用 css-module，代码

这本应是一种好的方式，但是在实际项目中开发者并不清楚其中的逻辑，并且在使用在也不规范，如手动直接调用大型组件的 less 文件的同时也调用其 css 文件。

应用 css-module 后会导致构建的文件体积变大，如果小项目，并且能自己管理好命名空间的情况下可以不开启，反之请开启。

另外关于 css-loader 自从版本 0.14.5 之后压缩耗时增加几十倍的问题，其实之前在本地做过相应的测试，

css-loader 分别尝试过 0.14.5 和 0.23.x

然后并没有在这个业务项目中发现问题，但不保证别的业务项目中会复现这个问题，基于此记录一笔。

官方 issue 地址

案例七 发布至 npm 的包并未 es5 化

目前在 atool-build 中处理 jsx 时并不会像处理 js 一样对 node_modules 目录下的内容进行屏蔽。

而现在在内部项目中可以看到大量的场景借 jsx 核没有 es5 化，这无疑是构建性能中巨大瓶颈的一块。

发布至 npm 的包，请全部 es5 化

综上开源世界的选择很多很精彩，但回过来头来想想我们是不是有点过分的利用了这份便捷，少了些对前端本身的敬畏呢。我们要合理适度的使用三方依赖，并认真思考每一步选择背后所需要承担的结果。

通过依赖的精简，使用上的规范，在构建速度上提升了 12秒，在代码压缩的情况下省下了约 900KB 的空间

从 webpack 自身优化点出发

在蚂蚁内部我们使用 atool-build 来进行前端资源文件的构建，如果并不清楚 atool-build 的同学可以前往 ant-tool/atool-build 文档 来进行了解。

笼统的说 atool-build 是基于 webpack 的构建工具，在其内部内置了一套通用型的 webpack 配置，同时这套配置通过 webpack.config.js 来进行重写。

atool-build 中已经内置优化

• CommonsChunkPlugin

在讲 CommonsChunkPlugin 前，可能大家需要理清楚一点是 entry 的概念，entry 在 atool-build 中更多意义上指的是一个页面的入口，这个入口对应一个 html 一个 js 一个 css，（这里并不排除不是这么做的，比如在 OLD IE 中对一个样式文件长度有限制，可能需要人为不得不进行拆分，这个时候借助 entry 或许是一种方式）如果在 multiple page 方案中就会有多个 entry，而 CommonsChunkPlugin 的作用是，在如上这些 entry 涉及的 chunk 中抽取公共部分的 module 合并进入一个 chunk；这里可能很多人有误区是认为抽取公共部分指的是能抽取某个代码片段，其实并不是，它是以 module 为单位的。

举几个典型的案例

现在有 entryA, entryB, entryC 和 entryD。

1）抽取 entryA, entryB, entryC, entryD 中所有公共部分的 modules（该 modules 必须都被所有 entry 所引用到） 进入一个 chunk

webpackConfig.plugins.push(
  new webpack.optimize.CommonsChunkPlugin('common', 'common.js')
)

2）抽取 entryA, entryB, entryC, entryD 中公共部分的 modules（该 modules 必须都被指定个数的 entry 所引用到） 进入一个 chunk

webpackConfig.plugins.push(
  new webpack.optimize.CommonsChunkPlugin({
    name: "commonOfAll",
    minChunks: 3
  })
)

3）只抽取 entryA, entryB 的公共部分

webpackConfig.plugins.push(
  new webpack.optimize.CommonsChunkPlugin({
    name: "commonOfAB",
    chunks: ['entryA', 'entryB']
  })
)

4）把 entry 中一些 lib 抽取到 vendor

首先可以在 entry 中设定一个 entry 名叫 vendor，并把 vendor 设置为所需要的 lib

webpackConfig.entry = {
  vendor: ['jquery']
}

webpackConfig.plugins.push(
  new CommonsChunkPlugin({
    name: "vendor",
    minChunks: Infinity,
  })
)

• DedupePlugin

DedupePlugin 在 atool-build 中的应用 代码定位

这个插件中可以在打包的时候删除重复或者相似的文件，实际测试中应该是文件级别的重复的文件，相似没测出来。这个优化对于还在使用 npm2 的同学会特别有用，因为 npm2 不像 npm3 对整体的依赖进行拍平。

举例

在 npm2 目录结构下直接打包如图依赖关系，并且 d 没有被 a 直接依赖，会出现 d 重复打包问题：

a
|--b
    |--d
|--c
    |--d

• OccurrenceOrderPlugin

该插件的功能是会在 resolve 所有的 module 后，对所有的 module 根据调用的次数重新给模块分配更短的 ids，从而减小最终构建产物的文件大小。该插件在 webpack2 中有类似的默认已经内置。在 atool-build 该插件默认内置。

• resolve.root vs resolve.modulesDirectories

在 webpack 官方站点 关于构建性能优化还提到了关于

resolve.root vs resolve.modulesDirectories

文中所说

Only use resolve.modulesDirectories for nested paths. Most paths should use resolve.root. This can give significant performance gains. See also this discussion.

atool-build 对其设置

resolve.root 一般情况下指向的是项目的根目录，是一个绝对路径；而 modulesDirectories 则是用以模块解析的目录名，一般情况下是相对路径。

简单来说把 resolve.modulesDirectories 设置为 ["node_modules", "bower_components"]

那么在项目中 foo/bar 的文件下依赖一个模块 a

那么 webpack 会通过如下的顺序去寻找依赖

foo/bar/node_modules/a
foo/bar/bower_components/a
foo/node_modules/a
foo/bower_components/a
node_modules/a
bower_components/a

反观我们的的 atool-build 中相关的设置是有优化空间的

尝试调整如下：

resolve: {
- modulesDirectories: ['node_modules', join(__dirname, '../node_modules')],
+ modulesDirectories: ['node_modules'],
}

调整完毕后，整体构建时长降低了 7s

webpack 提供的优化

• PrefetchPlugin

第一次接触这个插件来源于在 stackoverflow 上看到的一个问题 how-to-optimize-webpacks-build-time-using-prefetchplugin-analyse-tool

随后翻看了相关的文档，文档中提到可以用来 boost performance 听上去很诱人，但在实际使用中并没有那么顺利。

要使用 PrefetchPlugin 插件，首先需要了解清楚哪些依赖或者模块需要被 prefetch。而这些就需要衍生出 webpack cli 和 其 analyse 工具。

由 webpack ci json 把构建输出的日志生成到一个 json 文件中，然后通过 analyse 工具分析。

atool-build 目前已经内置了协助分析所需的 stats.json

$ atool-build --json

之后会在构建结果的目标目录会生成一个 build-bundle.json 基于数据安全原因建议大家自己搭建 analyse 平台，上传这个 json 文件查看效果。

上传完毕后，可以在页面最右侧的导航栏中可以看到 hints 这一级。点击之后便可以看到，Long module build chains 而 prefetch 的用意就在于实现 prefetch 一些文件或者模块以缩短 build chain。

举例在该项目中一处冗长构建链:

在这个案例中就可以把 babel-runtime 给 prefetch

new webpack.PrefetchPlugin('babel-runtime/core-js')

优化后，构建提速在毫秒级，效果不明显。

结论： preFetch 这类优化需贴合具体的应用场景，所以并不具有普遍性。对于构建速度的性能提升可能都不会明显。它的作用个人觉得是让你发现可能存在的性能问题，并通过 webpack 其他手段，比如之后会提到的 noParse 手段来解决其中的瓶颈

在此非常推荐一款 webpack 的插件，该插件可以让你清楚的看到代码的组成部分，以及在项目中可能存在的多版本引用的问题。

webpack-visualizer-plugin

在 atool-build 中使用只需要在 webpack.config.js 中做对应设置即可

var Visualizer = require('webpack-visualizer-plugin');
module.exports = function(webpackConfig) {
  webpackConfig.plugins.push(new Visualizer());

  return webpackConfig;
}

• external

简单来说 external 就是把我们的依赖申明为一个外部依赖，外部依赖通过 <script> 外链脚本引入。

在 atool-build 使用上

在 webpack.config.js 中

module.exports = function(webpackConfig) {
  ...

+ webpackConfig.externals = ['react', 'react-dom', 'react-router', 'classnames', 'immutable', 'g2']

  ...

  return webpackConfig;

};

并在对应的 entry 页面中通过 script 的方式传入这些库 cdn 的地址。

结论：提升整体构建时间 20s 以上，并在压缩代码的情况下省下约 1MB 的空间，个人比较推荐这种方式，因为有更好的 cdn 缓存加持。

• alias 和 noParse

如上我们已经知道如何声明一个外部依赖并通过 cdn 的方式来优化构建，这种方式是把依赖脱离了整个 bundle，可能有些情况下你需要把这个外部依赖打包进入到你的 bundle 但是你又不想为此而花费很长时间，如何做呢？

在 webpack.config.js 中

module.exports = function(webpackConfig) {
  ...

+ webpackConfig.resolve.alias = {
+   'react': 'react/dist/react.min'
+ }
+ webpackConfig.module.noParse.push(
+  /react.min/
+ )
  ...

  return webpackConfig;

};

经过如上设置，那么 require('react'); 等价于于 require('react/dist/react.min.js')

而 noParse 则会让 webpack 忽略对其进行文件的解析，直接会进入最后的 bundle

在项目中合理使用 alias 和 noParse 可以提升效率，但该选择更适合生产环境，否则调试时会比较尴尬

• DllPlugin 和 DllReferencePlugin

在正常项目中我们会发现除了自身代码外，我们的 deps 中也引用了大量的 npm 包，而这些包在正常的开发过程中并不会进行修改，但是在每一次构建过程中却需要反复的将其分析，如何来规避此类内耗呢？这两个插件就是干这个用的。

简单来说 DllPlugin 的作用是预先编译一些模块，而 DllReferencePlugin 则是把这些预先编译好的模块引用起来。这边需要注意的是 DllPlugin 必须要在 DllReferencePlugin 执行前，执行过一次。

那在 atool-build 中如何使用呢

给项目新增一个 dll.config.js

var join = require('path').join;
var webpack = require('atool-build/lib/webpack');
var pkg = require(join(__dirname, 'package.json'));
var dependencyNames = Object.keys(pkg.dependencies);

var uniq = require('lodash.uniq');
var pullAll = require('lodash.pullall');
var autoprefixer = require('autoprefixer');

var exclude = []

var deps = uniq(dependencyNames);
var entry = pullAll(deps, exclude);
var outputPath = join(process.cwd(), 'dll/');

module.exports = function(webpackConfig, env) {
  var babelQuery = webpackConfig.babel
  webpackConfig = {};

  webpackConfig = {
    context: __dirname,
    entry: {
      vendor: entry
    },
    devtool: 'eval',
    output: {
      filename: '[name].dll.js',
      path: outputPath,
      library: '[name]',
    },
    resolve: {
      modulesDirectories: ['node_modules'],
      extensions: ['', '.web.tsx', '.web.ts', '.web.jsx', '.web.js', '.ts', '.tsx', '.js', '.jsx', '.json']
    },
    resolveLoader: {
      modulesDirectories: ['node_modules'],
    },
    module: {

      loaders: [
        {
          test: /\.js$/,
          exclude: /node_modules/,
          loader: 'babel',
          query: babelQuery
        },
        {
          test: /\.jsx$/,
          loader: 'babel',
          query: babelQuery
        },
        {
          test: /\.tsx?$/,
          loaders: ['babel', 'ts'],
        },
        {
          test(filePath) {
            return /\.css$/.test(filePath) && !/\.module\.css$/.test(filePath);
          },
          loader: 'css?sourceMap&-restructuring!postcss',
        },
        {
          test: /\.module\.css$/,
          loader: 'css?sourceMap&-restructuring&modules&localIdentName=[local]___[hash:base64:5]!postcss',
        },
        {
          test(filePath) {
            return /\.less$/.test(filePath) && !/\.module\.less$/.test(filePath);
          },
          loader: 'css?sourceMap!' +
            'postcss!' +
            'less-loader?{"sourceMap":true}',
        },
        {
          test: /\.module\.less$/,
          loader: 'css?sourceMap&modules&localIdentName=[local]___[hash:base64:5]!!' +
            'postcss!' +
            'less-loader?{"sourceMap":true}'
        },
        { test: /\.woff(\?v=\d+\.\d+\.\d+)?$/, loader: 'url?limit=10000&minetype=application/font-woff' },
        { test: /\.woff2(\?v=\d+\.\d+\.\d+)?$/, loader: 'url?limit=10000&minetype=application/font-woff' },
        { test: /\.ttf(\?v=\d+\.\d+\.\d+)?$/, loader: 'url?limit=10000&minetype=application/octet-stream' },
        { test: /\.eot(\?v=\d+\.\d+\.\d+)?$/, loader: 'file' },
        { test: /\.svg(\?v=\d+\.\d+\.\d+)?$/, loader: 'url?limit=10000&minetype=image/svg+xml' },
        { test: /\.(png|jpg|jpeg|gif)(\?v=\d+\.\d+\.\d+)?$/i, loader: 'url?limit=10000' },
        { test: /\.json$/, loader: 'json' },
        { test: /\.html?$/, loader: 'file?name=[name].[ext]' },
      ]
    },
    postcss: [
      autoprefixer({
        browsers: ['last 2 versions', 'Firefox ESR', '> 1%', 'ie >= 8', 'iOS >= 8', 'Android >= 4'],
      }),
    ],
    plugins: [
      new webpack.DllPlugin({ name: '[name]', path: join(outputPath, '[name].json') })
    ]
  }

  return webpackConfig;
}

如上是把一个项目中的 deps 全部放入了 dll 中，运行如下命令后

atool-build --config dll.config.js

会在项目中生成一个 dll 文件夹其中包含了 vendor.dll.js 和 vendor.json

并在原有 webpack.config.js 中添如下代码片段

if (env === 'development') {
  webpackConfig.plugins.some(function(plugin, i){
    if(plugin instanceof webpack.optimize.CommonsChunkPlugin) {
      webpackConfig.plugins.splice(i, 1);

      return true;
    }
  });
  webpackConfig.plugins.push(
    new webpack.DllReferencePlugin({
      context: __dirname,
      manifest: require('./dll/vendor.json')
    })
  )
}

大功告成。

*请注意：dllPlugin 和 commonChunkPlugin 是二选一的，并且在启用 dll 后和 external、common 一样需要在页面中引用对应的脚本，在 dll 中就是需要手动引用 vendor.dll.js *

在实际使用中，dllPlugin 更加倾向于 开发环境，而对开发环境的整体提速非常明显。如下图所示，初次构建的速度优化约 20%，再次构建速度优化为 40%，hot-reload 约为50%

从 webpack 不足出发

• 单进程实现在耗 cpu 计算型 loader 中表现不佳，happypack 的用武之地

在 webpack 中虽然所有的 loader 都会被 async 并发调用，但是从实质上来讲它还是运行在单个 node 的进程中，以及在同一个事件循环中。虽然单进程在处理 IO 效率上要强于 多进程，但是在一些同步并且非常耗 cpu 过程中，多进程应该是优于单进程的，比如现在的项目中会用 babel 来 transform 大量的文件。所以 happypack 的性能提升大概就来源于此。 当然也可以预见到，如果你的项目并不复杂，没有大量的 ast 语法树解析层的事情要做，那么即使用了 happypack 成效基本可视为无。

在我这次尝试的优化项目中，400多模块都需要涉及 babel 加载，并且还存在 npm 包并没有 es5 的情况（bad），所以可以预见到的是会有不错的结果。

在 webpack.config.js 中添加如下代码片段

var babelQuery = webpackConfig.babel;
var happyThreadPool = HappyPack.ThreadPool({ size: 25 });
function createHappyPlugin(id, loaders) {
  console.log('id', id)
  return new HappyPack({
    id: id,
    loaders: loaders,
    threadPool: happyThreadPool,

    // disable happy caching with HAPPY_CACHE=0
    cache: true,

    // make happy more verbose with HAPPY_VERBOSE=1
    verbose: process.env.HAPPY_VERBOSE === '1',
  });
}
webpackConfig.module = {};

webpackConfig.module = {
  loaders: [
    {
      test: /\.js$/,
      exclude: /node_modules/,
      loader: 'happypack/loader?id=js',
    },
    {
      test: /\.jsx$/,
      loader: 'happypack/loader?id=jsx',
    },
    {
      test(filePath) {
        return /\.css$/.test(filePath) && !/\.module\.css$/.test(filePath);
      },
      loader: ExtractTextPlugin.extract('style', 'happypack/loader?id=cssWithoutModules')
    },
    {
      test: /\.module\.css$/,
      loader: ExtractTextPlugin.extract('style', 'happypack/loader?id=cssWithModules')
    },
    {
      test(filePath) {
        return /\.less$/.test(filePath) && !/\.module\.less$/.test(filePath);
      },
      loader: ExtractTextPlugin.extract('style', 'happypack/loader?id=lessWithoutModules')
    },
    {
      test: /\.module\.less$/,
      loader: ExtractTextPlugin.extract('style', 'happypack/loader?id=lessWithModules')
    }
  ],
}
if (!!handleFontAndImg) {
  webpackConfig.module.loaders.concat([
    { test: /\.woff(\?v=\d+\.\d+\.\d+)?$/, loader: 'happypack/loader?id=woff' },
    { test: /\.woff2(\?v=\d+\.\d+\.\d+)?$/, loader: 'happypack/loader?id=woff2' },
    { test: /\.ttf(\?v=\d+\.\d+\.\d+)?$/, loader: 'happypack/loader?id=ttf' },
    { test: /\.eot(\?v=\d+\.\d+\.\d+)?$/, loader: 'happypack/loader?id=eot' },
    { test: /\.svg(\?v=\d+\.\d+\.\d+)?$/, loader: 'happypack/loader?id=svg' },
    { test: /\.(png|jpg|jpeg|gif)(\?v=\d+\.\d+\.\d+)?$/i, loader: 'happypack/loader?id=img' },
    { test: /\.json$/, loader: 'happypack/loader?id=json' },
    { test: /\.html?$/, loader: 'happypack/loader?id=html' }    
  ])
} else {
  webpackConfig.module.loaders.concat([
    { test: /\.woff(\?v=\d+\.\d+\.\d+)?$/, loader: 'url?limit=10000&minetype=application/font-woff' },
    { test: /\.woff2(\?v=\d+\.\d+\.\d+)?$/, loader: 'url?limit=10000&minetype=application/font-woff' },
    { test: /\.ttf(\?v=\d+\.\d+\.\d+)?$/, loader: 'url?limit=10000&minetype=application/octet-stream' },
    { test: /\.eot(\?v=\d+\.\d+\.\d+)?$/, loader: 'file' },
    { test: /\.svg(\?v=\d+\.\d+\.\d+)?$/, loader: 'url?limit=10000&minetype=image/svg+xml' },
    { test: /\.(png|jpg|jpeg|gif)(\?v=\d+\.\d+\.\d+)?$/i, loader: 'url?limit=10000' },
    { test: /\.json$/, loader: 'json' },
    { test: /\.html?$/, loader: 'file?name=[name].[ext]' }
  ])
}
webpackConfig.plugins.push(createHappyPlugin('js', ['babel?'+JSON.stringify(babelQuery)]))
webpackConfig.plugins.push(createHappyPlugin('jsx', ['babel?'+JSON.stringify(babelQuery)]))
webpackConfig.plugins.push(createHappyPlugin('cssWithoutModules', ['css?sourceMap&-restructuring!postcss']))
webpackConfig.plugins.push(createHappyPlugin('cssWithModules', ['css?sourceMap&-restructuring&modules&localIdentName=[local]___[hash:base64:5]!postcss']))
webpackConfig.plugins.push(createHappyPlugin('lessWithoutModules', ['css?sourceMap!postcss!less-loader?sourceMap']))
webpackConfig.plugins.push(createHappyPlugin('lessWithModules', ['css?sourceMap&modules&localIdentName=[local]___[hash:base64:5]!postcss!less-loader?sourceMap']))
if (!!handleFontAndImg) {
  webpackConfig.plugins.push(createHappyPlugin('woff', ['url?limit=10000&minetype=application/font-woff']))
  webpackConfig.plugins.push(createHappyPlugin('woff2', ['url?limit=10000&minetype=application/font-woff']))
  webpackConfig.plugins.push(createHappyPlugin('ttf', ['url?limit=10000&minetype=application/octet-stream']))
  webpackConfig.plugins.push(createHappyPlugin('eot', ['file']))
  webpackConfig.plugins.push(createHappyPlugin('svg', ['url?limit=10000&minetype=image/svg+xml']))
  webpackConfig.plugins.push(createHappyPlugin('img', ['url?limit=10000']))
  webpackConfig.plugins.push(createHappyPlugin('json', ['json']))
  webpackConfig.plugins.push(createHappyPlugin('html', ['file?name=[name].[ext]']))
}

总结来说，在需要大量 cpu 计算的场景下，使用 happypack 能给项目带来不少的性能提升。从本次优化项目来看，在建立在 dll 的基础上，初次构建能再提升 40% 以上，重新构建也会提升 40% 以上。所以 dllPlugin 和 happypack 的结合可以大大优化开发环节的时间。

• uglifyPlugin 慢如蜗牛

uglify 过程应该是整个构建过程中除了 resolve and parse module 外最为耗时的一个环节。之前一直想要尝试在这个过程的优化，最近看社区新闻的时候，发现了 webpack-uglify-parallel 深入看了这个库的组织和实现，完全就是我需要的，因为它就是基于 uglifyPlugin 修改而来。

在 webpack.config.js 中启用 webpack-uglify-parallel 多核并行压缩

webpackConfig.plugins.some(function(plugin, i) {
  if (plugin instanceof webpack.optimize.UglifyJsPlugin) {
    webpackConfig.plugins.splice(i, 1);
    return true;
  }
});
var os = require('os');
var options = {
  workers: os.cpus().length,
  output: {
    ascii_only: true,
  },
  compress: {
    warnings: false,
  },
  sourceMap: false
}
var UglifyJsParallelPlugin = require('webpack-uglify-parallel');
webpackConfig.plugins.push(
  new UglifyJsParallelPlugin(options)
);

由于在 atool-build 中我们已经内置了 UglifyJsPlugin，所以一开始我们对该插件予以了删除。

结论：初次构建速度优化至少 40% 本地 8 核心 而服务端达到 20 核心。但是问题是在多核平行压缩中 cpu 负载非常高，如果服务端多项目并发构建，结果可能很难讲。需要有节制使用多核的并行能力。

• 最后大家可能很好奇，webpack-uglify-parallel 和 happypack 和 external 的混搭会带来怎么样的化学反应。

如上这个组合拳非常适合在生成环节下使用，而 dll + happypack 则更加适合在开发环节。

总结

本地构建时长 从原先的 125s 优化到了 36s，优化幅度为 70% 左右

本地调试时长从原先的 22s 优化到了 7s，优化幅度也为 70% 左右

webpack-uglify-parallel 和 happypack 和 external 的混搭非常适合在生产环节

dll + happypack 的混搭非常适合在开发环节

Ref: https://gitmoji.carloscuesta.me/

如上这个 emoji commit message 指引感觉非常好，所以大致翻译了下和大家分享

出发点源于最近在梳理和制定一套标准化且规范化开发细则，其中如何管理 commit 就是其中很重要的一个环节

借鉴了 angular 开发的规范，目前也是比较大规模使用的。

在指引文档中其中有一点涉及

Subject
The subject contains succinct description of the change:

• use the imperative, present tense: "change" not "changed" nor "changes"
• don't capitalize first letter
• no dot (.) at the end

其中就有 use the imperative, present tense，回过头想其实平时开发中很少有同学能把一些关键信息用简易且关键的英文动词来描述清楚此次 commit 的动机，而这篇指引一方面用了 emoji 这种形象化的方式外，关键多了解释说明，让我们这种英文不好的同学也能快速掌握到要领，同时可以把这些点，适用到 Subject 中。

🎨 :art: Improving structure / format of the code. 改进目录或代码结构 / 格式化代码

⚡ :zap: Improving performance. 提升性能

🔥 :fire: Removing code or files. 移除代码或文件

🐛 :bug: Fixing a bug. 修复 bug

🚑 :ambulance: Critical hotfix. 紧急修复

✨ :sparkles: Introducing new features. 新 feature

📝 :memo: Writing docs. 书写文档

🚀 :rocket: Deploying stuff. 部署相关

💄 :lipstick: Updating the UI and style files. 更新 UI 和 样式文件

🎉 :tada: Initial commit. 首次提交

✅ :white_check_mark: Adding tests. 新增测试用例

🔒 :lock: Fixing security issues. 修复安全性问题

🍎 :apple: Fixing something on macOS. 修复 macOS 平台上的缺陷

🐧 :penguin: Fixing something on Linux. 修复 Linux 平台上的缺陷

🏁 :checkered_flag: Fixing something on Windows. 修复 Windows 平台上的缺陷

🤖 :robot: Fixing something on Android. 修复 Android 上的缺陷

🍏 :green_apple: Fixing something on iOS. 修复 iOS 上的缺陷

🔖 :bookmark: Releasing / Version tags. 发布 / 给代码打版本化的 tag

🚨 :rotating_light: Removing linter warnings. 移除 linter 的警告

🚧 :construction: Work in progress. 开发进行时

💚 :green_heart: Fixing CI Build. 修复 CI 问题

⬇️ :arrow_down: Downgrading dependencies. 降级依赖版本

⬆️ :arrow_up: Upgrading dependencies. 升级依赖版本

📌 :pushpin: Pinning dependencies to specific versions. 锁死依赖版本

👷 :construction_worker: Adding CI build system. 添加 CI

📈 :chart_with_upwards_trend: Adding analytics or tracking code. 添加分析或埋点代码

♻️ :recycle: Refactoring code. 代码重构

➖ :heavy_minus_sign: Removing a dependency. 移除依赖

🐳 :whale: Work about Docker. Docker 相关事由

➕ :heavy_plus_sign: Adding a dependency. 添加一个依赖

🔧 :wrench: Changing configuration files. 修改一个配置文件

🌐 :globe_with_meridians: Internationalization and localization. 国际化和本地化

✏️ :pencil2: Fixing typos. 修正拼写错误

💩 :hankey: Writing bad code that needs to be improved. 需要改进的代码，先上后续再重构

⏪ :rewind: Reverting changes. 回滚变更

🔀 :twisted_rightwards_arrows: Merging branches. 分支合并

📦 :package: Updating compiled files or packages. 更新打包后的文件或者包

👽 :alien: Updating code due to external API changes. 外部依赖 API 变更导致的代码变更

🚚 :truck: Moving or renaming files. 移动或重命名文件

📄 :page_facing_up: Adding or updating license. 添加或者更新许可

💥 :boom: Introducing breaking changes. 不兼容变更

🍱 :bento: Adding or updating assets. 新增或更新 assets 资源

👌 :ok_hand: Updating code due to code review changes. 更新由 CR 引起的代码变更

♿ :wheelchair: Improving accessibility. 提升无障碍体验

💡 :bulb: Documenting source code. 书写源码文档

🍻 :beers: Writing code drunkenly.

💬 :speech_balloon: Updating text and literals. 更新文案以及字面量

🗃️ :card_file_box: Performing database related changes. 执行数据库相关变更

🔊 :loud_sound: Adding logs. 增加日志

🔇 :mute: Removing logs. 移除日志

👥 :busts_in_silhouette: Adding contributor(s). 新增贡献者

🚸 :children_crossing: Improving user experience / usability. 提升用户体验 / 可用性

🏗️ :building_construction: Making architectural changes. 架构变更

📱 :iphone: Working on responsive design. 真在进展响应式设计的相关事由

🤡 :clown_face: Mocking things. Mock 相关

🥚 :egg: Adding an easter egg. 彩蛋

🙈 :see_no_evil: Adding or updating a .gitignore file 新增或者更新 .gitignore 文件

在我的理解中支付宝小程序构建经历了两大过程

1. webpack 化

2. 去 webpack 化

看上去就好像走错了路，但话说回来任何的技术变更其实都没有清晰的界限来判定是对的还是错的，因为所有的决定都是基于当时的状态下决定的。

webpack 化

先来说一说为什么 webpack 化。
个人觉得 webpack 最大的魅力是有视万物为 module 的能力，它高阶的扩展能力，可以有极高的个性化能力；极其活跃的社区氛围或多或少可以让我们少走路，也少走弯路；另外不得不单独提一下 CRA，CRA 在开发体验优化这块上下的功夫非常深，目前很多基于 webpack 的上层封装，绝大多数都会有 CRA 的影子。
总结来说 webpack ：

• 优异的 add-on 设计
• 成熟的社区配套
• 活跃的社区氛围
• cra 提供了优异的开发体验模块

这些对于新生业务来说有着致命的诱惑力。
另外基于对原先 ant tool 的维护，使我成为了 webpack 死忠粉。所以自然而然我们采用了 webpack 做为构建的内核，另外基于它的 add-on 能力做了足够多的个性化能力输出。

确实一切看上去没什么大问题，除了 webpack 内置的缓存优化方案让我们坑了一次外没有任何的意外。

然而凡是都有个但是，随着小程序的一步步铺开，自然而然开发者的个性化需求开始见涨。正如大家所料到的越来越多的同学希望能开放核心的构建能力，更多的参数配置，webpack.config.js 又被搬上了台面。如果业务取向稳定，可控，那么 webpack.config.js 它绝对是滋生恶魔的来源，关于这一块探讨我在差不多2年前写过一篇文章构建工具的发展和未来的选择，这里就不再展开了，根本性问题我是担忧这给后续带来的维护性、稳定性、安全性问题。
由于 webpack 内置支持 pollyfill nodejs buildin 的模块，另外社区大库也不难发现他们也会很自然而然使用一些 module，但通常很多他们都会提供一个 dist 目录是纯可以跑在浏览器端的文件，而作为开发者，从我看到上千的项目使用中，我能保障90%的开发者没有这个意识，拿来即用成为了一种习惯。

这边扯出来另外一个话题，很有趣，我应该曾经2次在对外分享中问大家一个问题，如下代码，涉及了几种模块规范

import a from 'a';

const hello = require('./hello');

const d = {
  x: 1,
};
module.exports.c = function c() {};
exports.b = {};
export { d };

让人惊讶的是，能回答上来的人寥寥无几。

不知道大家有没有想过元罪是什么？是 webpack 这一类 universal 方案么? 还是 npm 把前端模块也引入了进来了？这是一个开放的命题没有标准答案。

回到正题，因为 webpack 巨大的包容性，当然这也怪我们当初没限死，慢慢的我们看到了在小程序业务中，居然出现了一类 cheerio 的依赖，看到越来越多的案例把传统 pc，node 开发思路慢慢的衍生到了小程序之上。做为我个人的观点，这是我不想看到的。

另外在调试环节下，小程序研发流程中用户会设置编译模式（即只调试固定页），webpack 这种贪婪式的编译模式（全量构建）是否真的契合小程序的调试模式。

于此之外，随着 WEB-IDE 的盛行，我们也琢磨着把编译流程整合到浏览器端，webpack 的厚重让可能性显得比较渺茫。

不过最最最重要的原因还是，webpack 在效率上还是显得有些局促，特别是在对比友商后，不过在这里要给 webpack 抱不平的是，webpack 的能力远大于友商的，而这种能力，就像现在的手机，它的算力是过剩的，而这种过剩的算力导致了时间的上累。

调研之路，友商带来的启发

友商在安全的防护上做的还是相当到位的，我很难通过 hack 的方式来窥视整个流程。
探究的过程中留给我最大的印象是对于克制的理解，产品层是克制的，功能是克制的，开放度是克制的。要真正在浮躁的互联网中做到还是挺难的。

接下来我们单纯从技术层面来说一说，以下都是我个人的理解，未必对。

友商的技术选型，按我的理解应该遵循四点：轻，快，可管控，够用就好。

这些方面可以体现在他们他们的任何一方面，框架、DSL、构建服务等。框架层友商相比蚂蚁，做的还是很薄的，蚂蚁背靠 react 生态，但这很有可能是把双刃剑，小程序真的 “小” 吗？我们是否做好了开放所带来的的管控问题？我觉得这些都是棘手的问题。而友商的轻薄，虽然在管控性上做的比较极致，但是面对开发者天马行空的需求，或许他们的问题更多的是如何来支持，典型的有一个案例就是 npm 支持，在蚂蚁这套技术体系下，我们是纯天然就支持现有的前端研发链路，所以在开发习惯的延续性上基本没有任何问题，但友商最初的做法是，让开发者在小程序生态外自己创建一个 npm 使用流程，这也就是为什么在社区里面为什么会有很多这类方案的原因，而后续友商发布支持 npm，但仔细琢磨，其实友商 npm 更加偏向于是 component 而不是非标准前端意义上模块，比如不支持 nodejs module shim 就可以看出。反观我们的 npm 目前已被玩坏。
另外在梳理过程中发现，友商的比如在处理 *xml 文件和 *css 文件时，它是解耦的，贪婪的。稍微深入一点就可以看到TA有专门的二进制编译工具在负责此类文件的编译，利用编译工具可以批处理诸如 *xml 和 *css 文件。这和我们之前基于 webpack 有着巨大的差异的，我们的编译本质上是有上下文的，即比如 component 样式会有作用域提升，进而影响 page，另外这当中大量依赖了 webpack 的语法分析 和 loader 机制，同此同时我们还依赖了一个让不属于构建但却又能影响构建的外部过程，所以从根本上我们在现有的技术架构上很难从真正意义上超越友商。
另外友商在框架层应该就考虑了模块加载，但我们在这一层依赖 webpack 提供的 runtime，所以友商对于模块的加载模式优化或者内部模块间的管控，比如控制 exports 有着更加灵活的空间，正因为这种模式，如果友商想要往比如 web-ide 靠其实有着更高的可行性。对于这一层的认知主要是我接触到了 Stackblitz，以及之后慢慢了解到了 Systemjs。这部分内容我放到下节。

通过友商的学习，更多的是让我感受到了小而美的力量，没有厚重的堆积感，确实能称得上 “小程序”。

CodeSandbox、Stackblitz 带来的启发

对于我来说，我的命题就是尽可能的让开发者以最快的速度来完成开发环境的初始化。我做过非常多的基于 webpack 的尝试，熟人常知的 happypack，cache-loader，thread-loader，hardsource，以及如何尽可能的让缓存增加有效性，以及甚至基于 webpack 的 memory fs hack 了一套自己的逻辑等等等等，但效果并不让人满意，甚至很多优化反而会导致很奇怪的问题。

很神奇有一次无意看到了友商在 worker 端代码的加载过程，可以看到的是 Ta 并没有真正意义上的 bundle 过程，对所有的 worker 进行了全量的 http 请求，我的第一个反应是 http 同源策略为什么他们还敢这样做，难道并发量不会成为瓶颈吗，这种方式我见不到对于webpack 的优势到底是什么？！很长时间带着这样的困惑，但这时 Stackblitz 走入到了我的眼前，最初就是他那篇 turboCDN 文章。我基本上挖坟了所有有关 Stackblitz 的 Issue Twitter。实际上 CodeSandbox 在这一块上也用着类似的方案，但 CodeSandbox 的问题是他在这块的实现在那会儿和其业务实现耦合非常深，所以我更加倾向的投向了 systemjs，至少它是独立的，且有自己的生态。随着更多的深入了解渐渐的我对他如何在浏览器内实现伪 bundle 和 npm 如何跑在浏览器端有了一定的了解。当时我的最大想法就是，我可以基于 systemjs 来实现一套动态和按需的加载方案，在本地开发阶段省去所有 bundle 过程，文件只有在真正用到时再进行编译，甚至通过一些方式比如在浏览器端实现 fs 那么这套方案就可以被移植到 web-ide 上。基于这样的构想，我开始了很长时间的尝试，从 18 年 10 月初我写下了第一行代码，代号被取为 Gravity，更多 Gravity 设计的内容我会放在下一段 。但在浏览器端实现 fs 和 利用 web worker 来实现 compile 上我碰到了很多壁，因为浏览器端没有 nodejs 环境，我要解决所有的 pollyfill 的问题，以及 文件 resolve 的差异性。然而时间上并不允许我做过多的技术性探究，所以在第一阶段我退而求其次，把这部分内容架设在了本地，通过启动一个 koajs 实例来解决，即浏览器端发生资源请求时，通过中间件（所处 nodejs 环境）来实现真正的编译过程。但是仅仅只是这一步尝试我把原先在 mac 上需要花 40s+ 的应用降到了 8s 左右，说实话我自己都没法相信。

通过学习 CodeSandbox、Stackblitz 带来的启发是利用纯浏览器带来的架构上的变更或许是另外一种出路。

再来谈谈 bundler 历史

最近有一篇文章出现在社区，题目是：A Future Without Webpack。如文中所说在过去的几年中 JavaScript 打包过程，一个原先仅仅面向于生产环境优化到现在成为 web 应用开发必要的一个步骤。不管你是喜欢也好，厌恶也罢，都很难否定一个事实，那就是它增加了 web 应用开发大量新的复杂度。而 web 领域一直来它所引以为傲的的点是，view-source 和 easy-to-get-started。这或许现在成为了一种讽刺。
为什么我们需要 bundler？
把时间倒退到六年前，那会儿我们对于打包的概念应该还是在 grunt 或 gulp 流式的任务处理，对资源文件的处理也仅仅是压缩和拼接。而后前端界兴起了模块化浪潮，模块化后的代码放在哪儿，又如何被引入相信这个问题是那会儿前端们最为关注的事情，所以又要翻翻老账 - seajs 有自己的源服务器来承载模块化后的模块也是非常自然的事情。但大家也都知道，世界上最大的代码源服务是 NPM，但如上文中提到的起始时 NPM = “Node.js Package Manager”，它并不真正意义上服务于前端浏览器。但是开发者对这一块的诉求实在是太大了，但 Node.js 众所周知使用的是 CJS 模块规范，所以不经过打包根本不可能运行于浏览器中，而诸多的模块定义，也给了像 Browserify, Webpack 空间，特别是 Webpack universal 的概念非常棒的契合了大家的诉求。

当然作者观点更多是当下已然是 2019 了，我们应该往前看，因为在浏览器端已经支持了 ESM。对我而言我觉得这种想要跳出困局寻求突破的精神是更加值得学习的。另外也抛给我一个问题，撇开作者的提供的思路或实现，是否本地 bundle 基于现有的技术架构，能否有所破局。

来谈谈新技术方案 Gravity

在谈 Gravity 前，还要来回首下我在几年前写的一篇文章 - 支付宝前端构建工具的发展和未来的选择，那会儿我们最大的困扰是配置带来的不可控性。所以那会儿我提出了构建因子以及 preset 的想法。基于对配置的敬畏所以在 Gravity 中我把这一套想法完全实现了出来（其实在那篇文章几个月后就有一版实现，但不幸的是没有继续深入流产了，另外也因为我工作内容被被动调整了）。

另外对于我看到了市面上各个公司都想往小程序上走，大家在小程序架构上都是大同小异，是不是有一种可能性能做一套构建底层来适配所有的小程序业务。这是我做 Gravity 的第二个念想。

所以 Gravity 的最 base 的架构思路是让 Gravity 变成构建工具的工厂，让各种业务形态的小程序构建变成 Gravity 的一种上层实现。要实现如上这个想法也就意味着，Gravity 必须要有好的插件机制。这个时候 tapable 自然而然成为了我的最佳选择，对于 tapable 渊源还要从我解析 webpack watch 实现说起，当然这不是我们今天的重点。重点是 webpack 就是基于 tapable 实现出来的，它的灵活性健壮性毋庸置疑，另外我彻彻底底研究过 tapable，真的是喜欢到不行。还有非常重要的一点是，我用 tapable 来设计插件机制，可以对开发者非常友好，因为基本没有学习的过程。

另外还有一个好处是基于 tapable 我可以非常轻松去实现一种时序，比如说我现在要实现一个 css 文件的加载 loader，在上文中我大概说了因为在时间上的原因我并未在一期就尝试把所有流程都丢到浏览器内完成，而是把一部分工作丢给了 koa 的中间件，所以在文件处理上（webpack 中叫 loader），我实现了一套动态生成中间件的方案，原因在于实现一个 css 文件的加载可能需要经过多个加载器，比如 post-css，css，style，这其中就有时序的问题，所以借由 tapable 我可以很方便来根据描述文件（类 webpack rules 设计）动态创建一个时序转而变成一个中间件。

在设计 gravity loader 时，和 CodeSandbox 一样，我们把 API 尽可能的往 webpack 靠了。原因就在于我想要有复用 webpack loader 的可能性。另外对于上层实现，也会更加友好，因为基本可以做到和 webpack 长得一样，用的一样。

另外还有很多细节我这里就不在阐述了。

Gravity 会进一步维护，也会在合适的时候开源。它的目标也非常明确，成为真正意义上浏览器端方案，在上层实现层可以对接到更多的业务场景。最终通过一个 web-ide 把所有的事情都串联起来。

总结

抛弃偏见，我相信 Cloud IDE 一定是未来，而面向 web 的架构一定是当务之急。

最近调研了所有 atool-build 使用方的代码，大概近千个项目，总结了一些常用的 webpack 方式，记录如下：

entry

entry 是描述一个 bundle 的入口文件是什么。在具体在业务中使用的方式有如下三种：

• 直接在 package.json 中描述 entry 内容；
• 动态创建 entry 内容，使用 glob 等工具使用若干通配符，运行时获得 entry 的条目，这种方式比较适合入口文件不集中且较多的场景；
• 根据 entry 内容挂钩一些 html 模板 loader，例如 html-webpack-plugin，ejs-html-loader 等，这种方式主要用以解决 html 随模板生成，但同时根据 entry 的一些内容自动替换模板中一些关键字。

output

output 的作用在于告知 webpack 该如何把构建编译后的文件放入到磁盘。

在具体业务中使用的方式有如下种：

• output.filename: 修改构建后文件的命名，业务中会存在 4 种情况。

  • 直接设置一个 bundle 的 name，例如 index.bundle.js 这类场景发生在只有一个 entry 的情况；
  • [name]，使用 Chunk 的名称
  • [hash]，使用 Compilation 的 hash 值，在这种方式下生成的资源文件会都有相同的 hash 值
  • [chunkhash]，使用 Chunk 的 hash 值，在这种方式下会根据每个 Chunk 的来生成 hash 值，使用这种方式的情况发生在想要 cache，cache 会衍生出很多的内容这个在之后再做展开。

• output.path: 修建构建后文件输出到磁盘的目录，业务中会存在 1 种情况。

• 传入一个相对于当前 cwd 的路径，这种自定义情况非常普遍

• output.publicPath: 申明构建后的资源文件的引入地址，业务中会存在 1 种情况

  • 设置为 https://xxxx.xx.com/assets/ 这种方式，这种方式的出现在于 webpack 默认在引用资源时都是从根目录开始，然后现实中 assets 资源 和 html 会随不同的发布平台发布。

• output.chunkFilename：声明非 entry chunks 的资源文件的命名，一般它发生的场景在 code split 即按需加载的业务场景，例如 require.ensure，在这种场景下，会对 require.ensure 的模块进行独立的打包，文件命名也会有四种情况。

  • [id]，id 值 从 0 开始
  • [name]，该 chunk 的 name，require.ensure(dependencies: String[], callback: function(require), errorCallback: function(error), chunkName: String)
  • [hash]，使用 Compilation 的 hash 值，在这种方式下生成的资源文件会都有相同的 hash 值
  • [chunkhash]，使用 Chunk 的 hash 值，在这种方式下会根据每个 Chunk 的来生成 hash 值，使用这种方式的情况发生在想要 cache，cache 会衍生出很多的内容这个在之后再做展开。

• output.library：一旦设置后该 bundle 将被处理为 library。

• output.libraryTarget：export 的 library 的规范，有支持 var, this, commonjs,commonjs2,amd,umd。

resolve

• resolve.alias：为模块设置别名。这种方案通常使用在两种情况下：

  • 一种是单纯为模块设置别名，一来方便自己不再需要根据目录书写 ../ 等这种路径操作，另外也可以提升 webpack 在 resolve 模块时的速度；
  • 另外一种则和优化上扯上一些关系，比如 resolve.alias.a = isTest ? 'moduleTestA' : 'moduleA'，如上这种方式使用最大的好处在于能根据当前所属代码所需情况构建产物中只会有 moduleTestA 或者 moduleA。以上这种方式可以在所有资源文件应用。当然也可以使用 babel-plugin-module-resolver 和 less-plugin-rewrite-import 予以解决。

• resolve.root：添加个人目录到 webpack 查找模块的路径里，这种需求比如发生在当前某个项目所依赖某个文件并不在该项目中。

• resolve.modulesDirectories：模块解析方式，在项目中我看到一般会有两种使用的场景，

  • 一种主要针对开发者，需要新增一种模块的解析方式。比如设置为 ["node_modules", "bower_components"] 那么在项目中 foo/bar 的文件下依赖一个模块 a, 那么 webpack 会通过如下的顺序去寻找依赖

    foo/bar/node_modules/a
    foo/bar/bower_components/a
    foo/node_modules/a
    foo/bower_components/a
    node_modules/a
    bower_components/a
    

  • 另外一种则是想要申明模块 resolve 的优先级，比如在一个项目中有依赖 A，B，依赖的 A,B 同时依赖了 C，如果在构建过程中，你想明确表示我只想要某个 C 的话，则就可以通过这种方式。

• resolve.extensions：设置解析模块的拓展名。默认为 ["", ".webpack.js", ".web.js", ".js"]。比如新增一种文件扩展名，["", ".webpack.js", ".web.js", ".web.ts", ".web.tsx", ".js"]

• resolve.packageMains：设置 main 的入口文件。这种方式目前会在 webpack@2 中使用 resolve.mainFields 来解决 tree-shaking，目前支持的有 redux 等。

resolveLoader

• resolveLoader.modulesDirectories：同 resolve.modulesDirectories 只不过针对 loader，这边需要注意的是在 resolve.modulesDirectories 中关于优先级的，在工具被二次封装时会用到比较多。
• resolveLoader.moduleTemplates： ["*-webpack-loader", "*-web-loader", "*-loader", "*"] webpack@1 中内置的模板，但是在 webpack@2 是并不会补齐。

resolve.root, resolve.fallback, resolve.modulesDirectories 这三个属性在 webpack@2 中被合并到了 resolve.modules

module

• module.loaders：对应模块的加载器。在 webpack@2 中使用 module.rules 予以取代。以下会罗列目前常用文件类型的模块加载处理方式。
  • babel-loader 处理 .js 和 .jsx 文件，由于历史原因 atool-build 在处理 .jsx 文件时会处理 node_modules 下内容。
    • 目前 atool-build 已经内置的 preset 有 babel-preset-es2015-ie，babel-preset-react，babel-preset-stage-0，plugins 有 babel-plugin-add-module-exports 和 babel-plugin-transform-decorators-legacy。
    • 目前业务中自行使用的有: plugins: babel-plugin-import 构建资源大小提供优化，babel-plugin-transform-runtime 实现按需加载 pollyfill 需要与 babel-runtime 结合使用，babel-plugin-module-resolver 实现诸如 webpack 中 resolve.alias 功能，babel-plugin-dva-hmr 和 babel-plugin-dev-expression 实现 dva hot module replacement 功能，babel-plugin-react-intl 实现 react 多语言方案， babel-plugin-es6-promise 覆盖原有 promise; preset: babel-preset-env 实现根据浏览器支持情况自动打包 pollyfill 等功能，babel-preset-es2016 等。**在实际过程中，都可能需要对 preset 传入参数的需求。**一般设置如下
      • presets: [[require.resolve('xxx-preset'), { options: hi }]]
    • cacheDirectory：缓存支持，一般默认就开启
    • babelrc：一般需要禁用掉，防止用户端的 babel 配置影响内置配置
  • tsx-loader: 处理 ts 文件，内置参数 target: 'es6', jsx: 'preserve',moduleResolution: 'node', declaration: false, sourceMap: true，需要注意的是在使用 ts 项目时必须要人为引入一个 ts config.json 的文件，如果没有内容，内部设置为一个空对象即可。
  • style-loader: 通过 js 方式 inject style 节点来注入样式，一般用于开发环境
  • css-loader: 处理 css 文件，一般现有项目中都会使用 ExtractTextPlugin 把样式文件抽取出来，但是在本地开发环境下一般不会 extract 出来，因为一旦 extract 出来会导致 hmr 对样式失效。所以一般在开环环境下会 style-loader!css-loader!postcss-loader 而在 production 下采用 ExtractTextPlugin，另外在每个 loader 都有对应的参数，postcss 还有专门的插件集。除此之外，常用的 css-loader 参数有 modules autoprefix indentName 等
  • postcss-loader: 目前在 postcss 中内置的 plugin 有 rucksack-css - 可废弃 和 autoprefixer 用以实现 autoprefix。一般针对适配的不同的浏览器，需要对 autoprefixer 配置 browsers 参数。一般在无线业务中为了适配高清方案也会引入 postcss-plugin-pxtorem, 同时也需要设置一些参数。
  • less-loader: 处理 less 文件，一般情况下需要配置 modifyVars 参数，用以覆盖 less 变量值
  • sass-loader: 处理 sass 文件，也有使用 fast-sass-loader 和 @ali/sass-loader
  • file-loader: 处理 html 文件，当前 atool-build 内置的方式，在实际业务中，很多并不希望 html 是拍平的结构，所以他们会自定义 fileloader 的参数，比如 file?name=[path][name].[ext]&context=./src/pages，但是也有不少业务中对 html 处理引入了新的 loader, 有 ejs-html-loader，html-minify-loader，还有直接使用插件 HtmlWebpackPlugin 来处理的情况，经过研究，根本上其实是想要解决 html 的自动化生成，以及内部资源文件的引用可以自动化生成。
  • url-loader: 处理 woff woff2 ttf eot svg png jpg jpeg gif 文件，目前业务中会有变更的点有，需要设置 limit 的大小，以及 svg 的处理可能需要存在多个 loader 处理，因为在使用 antd-mobile 业务中需要新增一个 svg-sprite-loader 来把 svg 文件当成一个 component
  • svg-sprite-loader, 已在 url-loader 中予以说明
  • HtmlWebpackPlugin, 已在 file-loader 中予以说明
  • ejs-html-loader, 已在 file-loader 中予以说明
  • html-minify-loader, 已在 file-loader 中予以说明
  • handlebars-loader, 处理 .handlebars 文件，并未内置，业务中自行引入
  • aptl-loader, 处理 .atpl 文件
  • raw-loader, 处理 tpl 文件，也有使用 html-loader 来处理的
  • scss-loader, 处理 scss 文件
  • vue-loader, 处理 vue 文件
  • json-loader, 处理 json 文件
    注：一个正常 loader 的配置可能需要配置 test,exclude,include,loader,loaders属性
• module.preLoaders：istanbul-instrumenter，此方式在 webpack@2 中被弃用，可以直接在对应的应用规则的文件中启用 enforce: 'pre'
• module.postLoaders：es3ify-loader，提升 ie 兼容性，此方式在 webpack@2 中被弃用，可以直接在对应的应用规则的文件中启用 enforce: 'post'
• module.noParse: 指明 webpack 不去解析某些内容，该方式有助于提升 webpack 的构建性能，配置内容可以是

externals

目前业务中使用都为声明外部依赖，这种方式有益于加速 webpack 构建，但是需要开发者额外引入被 external 库的 cdn 地址，常见的有 React 和 ReactDom。

devtool

文档

node

目前内置如下内容为 empty

  [
    'child_process',
    'cluster',
    'dgram',
    'dns',
    'fs',
    'module',
    'net',
    'readline',
    'repl',
    'tls',
  ];

plugin - webpack 内置

大部分插件都有需要参数传入

• webpack.optimize.CommonsChunkPlugin，在业务中通常有两种使用方式，一种是直接从所有的代码中抽取 common 的逻辑，此处可以配置 common 抽取最小单元，还有一种 common 的使用方式是 vendor 即用户配置具体的 entry 条目，并把该条目抽取为 vendor。
• webpack.optimize.OccurenceOrderPlugin：优化插件，优化 module id
• webpack.optimize.UglifyJsPlugin：代码丑化
• webpack.optimize.DedupePlugin：打包时删除重复模块代码
• webpack.DefinePlugin：给代码注入全局标识符
• webpack.BannerPlugin：给代码添加 banner 信息
• webpack.ProvidePlugin：调用模块的别名
• webpack.NoErrorsPlugin：报错但不退出webpack进程
• webpack.ProgressPlugin：显示构建进度
• DllPlugin：主要业务中应用于提升本地调试速度，配置需要有单独的 Dll 配置文件
• DllReferencePlugin：主要业务中应用于提升本地调试速度，需要配合 DllPlugin 使用

plugin - webpack 扩展

大部分插件都有需要参数传入

• webpack-visualizer-plugin：查看构建 bundle 的构成
• html-webpack-plugin：生成 html 文件
• copy-webpack-plugin：拷贝文件或者文件夹
• clean-webpack-plugin：清理文件或者文件夹
• i18n-webpack-plugin：国际化支持
• webpack-shell-plugin：给 shell 提供运行时机
• case-sensitive-paths-webpack-plugin： 路径大小写敏感问题
• friendly-errors-webpack-plugin：友好报错信息
• extract-text-webpack-plugin：将文本内容生成抽取成独立文件
• happypack：加速构建，需要对配置做比较大改动
• parallel-webpack： 提供资源文件的并发构建
• map-json-webpack-plugin：使用 hash 时，生成资源映射文件

需要沉淀的方案

• html 自动化生成，自动更新引用资源
• 更加优质的 common 生成逻辑
• 目前有持久化缓存需求，需要给出一个更加完善的方案，即更加合理化的 hash 方案
• https://github.com/goldhand/sw-precache-webpack-plugin 通过 sw 来完成资源文件离线化
• 单一文件多种 loader 处理，单一文件多种 loader 如何进行区间调整

前一阵子和 @sorrycc 聊天，我们都谈到了自己很久没有写文章了，差不多有半年了吧，罪恶感油然而生。我们的 CC 同学对自己更狠一些，他建了一个监督群，没有按时完成任务会罚钱。

我么给自己的 2019 年定一个计划

第一个中心点： gravity

gravity 是一个架设于魔改 systemjs 之上的调试构建工具。为什么会做他，为什么不用 webpack 可能订阅了我的 blog 的同学会有这样的疑问，我也是经过了非常多的考虑和实践之后才做的决定。这些内容都会在后面一一来回答大家。

gravity 这个方案让我非常激动，做了几年的工具，终于有机会把所有的想法付诸于这个方案上了，目前我们已经在内部获得了还算不错的效果，达到足够稳定之时，秉着开源的精神，也秉着让这个方案拥有更强的通用性，我也会逐步开源。

第二个中心点：猪罐头

猪罐头是我的个人公众号，里面主要讲讲我的业余生活，在这里无关代码，只有诗和远方。

第三个中心点：铿锵三人行

这个事情是我，@sorrycc 还有 范公子我们三个人在杭州南山路酒吧 - ink 墨水，拍脑袋的决定。我们想要做一个访谈，比较轻松的形式，地点也会选在咖啡厅，酒吧等一些比较轻松的位置。大家邀请一个嘉宾，围绕一个主题，各自谈谈自己的想法。

但是，目前我们的 @sorrycc 反悔了，大家赶紧去说服他！😁

蚂蚁金服微贷前端技术团队招聘公告

业务介绍

Hi，你现在看到的内容是一篇充满诚意的前端紧急招聘公告。我们团队来自 蚂蚁金服-微贷事业部，目前业务战略重大升级，急切需要大量前端人才加入，P5、P6（资深）、P7（专家/TL）、P8（高级专家/TL） 不限！

我们的业务明星产品线有：花呗、借呗、网商银行。

**花呗、借呗 **是国民普惠级的消费信贷产品，下设核心产品、规模、场景、用户粘性、市场等多条产品线和子产品，拥有数亿级的消费者群体，深受广大用户喜爱。
**网商银行 **是国内第一家云上的银行，包含了转账、存款、融资、理财等各类金融服务，致力于成为**小微企业首选综合金融服务商。

部门从诞生开始就梦想着『让信用等于财富』，实践着『每个认真生活的人，都值得被认真对待』。微贷技术的伙伴们用多年的时间诠释了『理想、行动、坚持』这六个字。在未来，我们还有更长的路要走，我们希望用金融科技+数据智能化的开放创新，让普惠金融真正的触手可及。

团队介绍

作为蚂蚁金服最具明星气质的金融业务，必须要有一支具备明星气质的前端团队。

• 我们的产品业务中大量应用着基于 react 的产品研发体系，同时在参与维护 umi（蚂蚁开源的移动前端解决方案）及其 plugin 的内部生态建设，因此我们特别需要对 react 玩得6的你。
• 我们的营销业务中全面启用了基于 vue 的营销技术体系，同时开始启动 sherry 项目（蚂蚁内部的营销解决方案），因此我们也特别需要对 vue 玩得6的你。
• 我们手中的 BFF 系统可能是国内最大流量的对 C 的 nodejs 系统，参与 egg（蚂蚁开源的企业级 nodejs 框架） 以及相关中间件的研发建设工作，因此我们还特别需要对 nodejs 服务端玩得6的你。
• 我们的互动业务中大量应用了 2D/3D 的动画和游戏，同时也在负责 R3（蚂蚁内部的 3D 渲染引擎）以及蚂蚁的互动技术平台的建设工作，因此我们同样特别需要对 WebGL 等图形互动技术玩得6的你。
• 我们还在负责 ant design mobile（蚂蚁开源的移动组件库）的维护工作，因此还特别需要对移动组件研发玩得6的你。
• 我们的中后台业务中有太多的可视化场景，因此我们仍特别需要对数据可视化玩得6的你。

我们有太多的事情想做，不能缺少你。

我们还会提供什么？

• 欢乐而又激情的娱乐氛围。曾经联合了众多大佬、火遍前端届的 Hiphop《小翔很嘻哈》就是我们团队小伙伴们的业余神作。内网还有我们更多火爆的作品，等着你进来了解。
• 充满朝气而又开放的生活氛围。每周都会有团队运动日，每个月组织定期的团建，每年一度的 outing 欢乐时光。每周固定的分享会、每月一度的联合技术交流会，同时还会做专门的预算鼓励大家走出公司，积极参与各类国内外的行业分享交流会议。团队成员也曾在 qcon、react dev conf、蚂蚁 atec、网易开发者大会 等技术会议上担任分享嘉宾。
• 忙碌而又充实的工作氛围。跟你一起并肩战斗的是一个个年轻而充满激情和理想主义的伙伴们。我承诺你会很忙，但同时承诺你也一定会收获更多的技术成长和极大的发展空间。

我们有太多的快乐要分享，不能缺少你。

岗位要求

前端工程师（基础要求）：

1. 2年以上工作经验。如果你觉得自己特别优秀，1-2 年经验同样欢迎。
2. 具备良好的 HTML/CSS/JS 前端基础，有 react / vue 等主流框架开发经验，并深入理解其原理，熟悉 webpack；
3. 对互联网产品和 Web 技术有浓厚兴趣，有强大的自我驱动能力、学习能力和强烈的进取心；
4. 良好的沟通能力和团队合作精神，良好的分析问题和解决问题的能力；

在上述基础要求的基础上，设置六大方向：

移动前端方向：

• 需熟练掌握移动端 H5 / hybrid 开发；
• 对移动前端性能优化有充足的实践和方法；
• 有小程序开发经验优先。

nodejs 全栈方向：

• 熟悉 node.js 异步编程，对 koa/co/async 等原理机制了解透彻；
• 熟悉 node.js 以及 V8 的性能和稳定性优化，能对系统整体性能进行评估，解决内存瓶颈；
• 熟悉监控和运维体系，有大流量高并发经验优先。

互动技术方向：

1. 精通 Canvas/WebGL/SVG/CSS3，并能够使用原生 API 绘制图形动画；
2. 熟悉业界流行渲染引擎或游戏开发框架，熟练掌握其中至少一种并具备实际开发经验；
   
3. 有 3D 游戏开发经验优先。

基础架构方向：

• 具备良好的抽象能力和架构设计经验，至少以架构角色参与过一个中大型前端开发项目；
• 扎实的数据结构、算法和编程基本功；
• 有良好的开源作品和社区参与经验，关注新技术。

中后台方向：

• 精通主流 web 技术，主导与组织过复杂的 web 项目开发；
• 对前端工程化、标准化、组件化有充足的实践和方法；
• 有可视化搭建经验优先。
  

数据可视化方向：

1. 了解业界目前发展及现有作品及主流工具，对于数据可视化有一定个人见解；
2. 相关工作经验 2 年或以上，了解 Canvas/WebGL/SVG/CSS3 技术，至少熟悉一种数据可视化 JS 类库；
3. 具有计算机图形学理论基础，熟悉数据可视化相关基础算法。

工作地点：

杭州/北京 （人数不限！）

联系方式：

简历投递至我的个人邮箱：[email protected]

示例仓库

在讲 lerna workflow 前我们先粗话来谈下当今主流的项目代码管理方式

杂谈项目管理方式

multiRepos

multiRepos 它是一种管理 organisation 代码的方式，在这种方式下，独立功能会拆分成独立的 repo

这是最常见的项目管理方式

优点:

• 功能拆分颗粒度较细，职责界线清晰，功能性模块复用度较高

缺点:

• 由于历史原因或者拆分问题，一个 repo 内的依赖可能来源于多个 organisation
  • issue 提哪是个问题
  • 项目管理，工作协同比较糟糕
• 维护成本较高
  • 任何的基层 repo 版本变更，将会引发一系列上层封装版本变动
• changelog 梳理异常折腾
  • 基本靠口口相传

monoRepo

Monorepo 它是一种管理 organisation 代码的方式，在这种方式下会摒弃原先一个独立功能一个 repo 的方式，取而代之的是把所有的 modules 都放在一个 repo 内来管理，而 lerna 是基于此种理念在工具端集合 git 和 npm 的实现。

优点:

• 功能依旧可以拆分的细粒度
• one repo multiple packages 让项目管理比较方便，issue 管理，代码变更都能比较好清晰的体现给协同开发者
• child package 版本变更会自动化同步至相关的 package

缺点:

• monoRepo 体积都比较大
• 配套工具 lerna 有一定的使用成本，开发者比较容易用错，另外它有一些约定俗成，不能妥协的规范，以及限制
  • 对 packages 内的依赖版本管理只能 ^
  • 不支持多个 registry 的推送
  • 等等
• 配套的 changelog 方案只适配于 github 详见我的另外一篇文章 - introduce lerna，如果是社区项目非常推荐走这一套方案
• 版本的生成还是存在一定的缺陷，开发者并不知情 break 等信息

总结

项目开发中使用 multiRepos 和 monoRepo 都可以，问题在于项目合不合适。

个人角度上:

合适的项目需要有以下特征

• 存在多个 package
• package 与 package 之间相互依赖

符合以上条件我个人比较建议采用 monoRepo，以及与之带来的 lerna workflow。

当前使用 lerna确实还会有些小问题，这也是我们需要解决的点。

lerna workflow

先再次简单的介绍下 lerna

Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm.

lerna 模式

在初始化一个项目之前我们必须要清楚，lerna 对管理 monoRepo 有两种模式

• Fixed/Locked mode (default)
• Independent mode

Fixed/Locked 模式: 官方默认推荐模式，当前 babel 的项目管理模式，在该模式下所有的 packages 都会遵循一个版本号，该版本号维护在 lerna.json 的 version 字段中，当需要版本发布时 lerna publish 时，如果一个模块和上一次 release 相比有过变更的话，会自动发布一个新版本。

这种模式的问题在于：当有一个 major 变更的时候，所有 packages 都会都会有一个新的 major 版本。

维护团队认为：版本是一种非常 cheap 的东西，所以不必纠结。

Independent 模式: 在该模式下所有 packages 新版本的生成将会由开发者决定，lerna.json 的 version 字段也会随之失效。这种模式的弊端非常明显，开发者必须要非常清晰该发什么版本，事实上在多人协作项目上很难做到这一点。

简单命令速记

init

$ lerna init

初始化一个 lerna 项目

add

$ lerna add <package>[@version] [--dev]

默认给当前所有的 packages 添加一个依赖

这边需要推荐一个比较有用的命令

$ lerna add module-1 --scope=module-2 # Install module-1 to module-2
$ lerna add babel-core # Install babel-core in all modules

这种方式是可以快速建立 packages 的依赖关系，而不用人为手动建立

bootstrap

$ lerna bootstrap

这个命令会安装好所有 packages 的依赖，以及建立好 packages 相互依赖的软连接

正式流程为：

1. 安装所有 package 的外部依赖.
2. 对存在相互依赖的 package 创建软连接.
3. 在所有已经 bootstrapped 的 package 中执行 npm run prepublish.
4. 在所有已经 bootstrapped 的 package 中执行 npm run prepare.

publish

$ lerna publish

发布一个版本。

正式流程为：

1. 执行 lerna updated 来确定哪些包需要被发布.
2. 如有必要会升级 lerna.json 的 version 字段。
3. 对所有需要 update 的 package 进行版本的更新，并写入他们的 package.json.
4. 队友有需要 update 的 package 进行依赖申明 specified with a caret (^).
5. 创建一个 git commit 和 tag
6. 把包发布至 npm

较为有用的附加参数

--npm-tag

$ lerna publish --npm-tag=beta

使用传入的 tag 把包发布至 npm 对应的 dist-tag

--conventional-commits

$ lerna publish --conventional-commits

遵从 Conventional Commits Specification 进行版本生成和 changlog 生成。

--skip-git

$ lerna publish --skip-npm

跳过 git 打标

--skip-npm

$ lerna publish --skip-npm

跳过 npm 发布

--cd-version

$ lerna publish --cd-version (major | minor | patch | premajor | preminor | prepatch | prerelease)
# uses the next semantic version(s) value and this skips `Select a new version for...` prompt

指定发包的时的语义版本

clean

$ lerna clean

移除所有 package 下的 node_modules 目录.

import

$ lerna import <path-to-external-repository>

从现有仓库导入一个 package，这种方式下会保留原有的 commit 的信息

run

$ lerna run <script> -- [..args] # runs npm run my-script in all packages that have it
$ lerna run test
$ lerna run build

# watch all packages and transpile on change, streaming prefixed output
$ lerna run --parallel watch

执行 package 下 npm script

exec

$ lerna exec -- <command> [..args] # runs the command in all packages
$ lerna exec -- rm -rf ./node_modules

在任何 package 下执行任意的命令

getting started

step 1:

$ npm install --global lerna

step 2:

$ mkdir lerna-example
$ cd lerna-example

step 3:

$ lerna init

运行完后在 terminal 中执行 tree 后我们可以看到此时的目录结构为

➜  lerna-example git:(master) ✗ tree
.
├── lerna.json
├── package.json
└── packages

step 4:

$  packages git:(master) ✗ mkdir module-a && cd module-a && touch index.js && tnpm init
$  packages git:(master) ✗ mkdir module-b && cd module-b && touch index.js && tnpm init
$  packages git:(master) ✗ mkdir module-base && cd module-base && touch index.js && tnpm init

运行完后在 terminal 中执行 tree 后我们可以看到此时的目录结构为

➜  lerna-example git:(master) ✗ tree
.
├── lerna.json
├── package.json
└── packages
    ├── module-a
    │   ├── index.js
    │   └── package.json
    ├── module-b
    │   ├── index.js
    │   └── package.json
    └── module-base
        ├── index.js
        └── package.json

step 5:

如果已知 module-base 被 module-a 和 module-b 共同依赖，同时 module-a 又 依赖 module-b

➜  lerna-example git:(master) ✗ lerna add @alipay/module-base
➜  lerna-example git:(master) ✗ lerna add @alipay/module-b --scope=@alipay/module-a

项目中使用的问题

在协同开发时，假设如果开发人员在 module-base 上发布了一个并不兼容的提交，此时做为 pm 的同学很难在没有提前沟通的情况下获知此次变更，所以在选择版本发布时也很容易出现，因为 lerna 默认对依赖的描述是 ^，所以这在信息不对称的情况下很容易造成线上故障。

如何破局呢？

• github 用户使用 introduce lerna 文中提及的 lerna-changelog 来依据 changelog 来管理，这个方案的缺点是，版本号生成时并不是完全自动化的，还是需要人工介入。
• 非 github 用户或使用 commitizen 用户，可以借由 --conventional-commits，来自动化生成版本以及 changelog

关于 commitzen 相关的可以看我另外一篇文章 用工具思路来规范化 git commit message

第二种方案也是目前我们项目中应用最多的。

应用 commitizen 方案后， package.json 变更为

{
  "private": true,
  "scripts": {
    "ct": "git-cz",
    "changelog": "./tasks/changelog.js",
    "publish": "./tasks/publish.js"
  },
  "config": {
    "commitizen": {
      "path": "./node_modules/cz-lerna-changelog"
    }
  },
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -e $GIT_PARAMS",
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.js": [
      "prettier --trailing-comma es5 --single-quote --write",
      "git add"
    ]
  },
  "devDependencies": {
    "@alipay/config-conventional-volans": "^0.1.0",
    "@commitlint/cli": "^6.1.3",
    "commitizen": "^2.9.6",
    "cz-lerna-changelog": "^1.2.1",
    "husky": "v1.0.0-rc.4",
    "lerna": "^2.10.2",
    "lint-staged": "^7.0.4",
    "prettier": "^1.11.1"
  },
  "dependencies": {
    "fs-extra": "^6.0.0",
    "inquirer": "^5.2.0",
    "shelljs": "^0.8.1"
  }
}

commitizen 应用后仓库结构说明

packages 目录下存放的是所有的子仓库
tasks 目录下存放一些全局的任务脚本，当前有用的是 publish.js 和 changelog.js

• changelog.js，当有发布任务时，请事先执行 npm run changelog，此举意为生成本次版本发布的 changelog，执行脚本时会提醒，本次发布是正式版还是 beta，会予以生成不同版本信息供予发布
• publish.js，当 changelog 生成并调整相关内容完毕后，执行 npm run publish，会对如上所有的子 packages 进行版本发布，执行脚本时会提醒，本次发布是正式版还是 beta，会予以不同 npm dist-tag 进行发布

日常开发流程

在常规开发中，我们的操作方式会变更为如下：

第一步：使用 commitizen 替代 git commit

即当我们需要 commit 时，请使用如下命令

$ npm run ct

如果你在全局安装过 commitizen 那么，直接在项目目录下执行

$ git ct

执行时，会有引导式的方式让你书写 commit 的 message 信息

如果你是 sourceTree 用户，其实也不用担心，你完全可以可视化操作完后，再在命令行里面执行 npm run ct 命令，这一部分确实破坏了整体的体验，当前并没有找到更好的方式来解决。

关于为什么需要 commitizen，可以参考 这篇文章

当前我们遵循的是 angular 的 commit 规范。

具体格式为:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

type: 本次 commit 的类型，诸如 bugfix docs style 等
scope: 本次 commit 波及的范围
subject: 简明扼要的阐述下本次 commit 的主旨，在原文中特意强调了几点 1. 使用祈使句，是不是很熟悉又陌生的一个词，来传送门在此 祈使句 2. 首字母不要大写 3. 结尾无需添加标点
body: 同样使用祈使句，在主体内容中我们需要把本次 commit 详细的描述一下，比如此次变更的动机，如需换行，则使用 |
footer: 描述下与之关联的 issue 或 break change，详见案例

第二步：格式化代码

这一步，并不需要人为干预，因为 precommit 中的 lint-staged 会自动化格式，以保证代码风格尽量一致

第三步：commit message 校验

这一步，同样也不需要人为介入，因为 commitmsg 中的 commitlint 会自动校验 msg 的规范

第四步：当有发布需求时，先生成 changelog

使用

$ npm run changelog

在这一步中我们借助了 commitizen 标准化的 commit-msg 以及 lerna 中 publish 的 --conventional-commits 来自动化生成了版本号以及 changelog，但过程中我们忽略了 git tag 以及 npm publish （ --skip-git --skip-npm），原因是我们需要一个时机去修改自动化生成的 changelog。

第五步：再发布

由于第四步中，我们并没有实质意义上做版本发布，而是借以 lerna 的 publish 功能，生成了 changelog，所以后续的 publish 操作被实现在了自定义脚本中，即 publish.js 中。

$ npm run publish

> 第六步：打 tag

给当前分支打好对应的 git tag 信息，推送到开发分支

本个系列的文章会被分成两篇文章

（一）主要描述下问题的表现，并 dive into webpack watch system
（二）解决问题，从根本上解决 webpack 的 bug

最近做一个内部工具时碰到了一个很有意思的问题

多次 rebuild 的现象

当首次动态创建 webpack 入口文件后，入口文件新增依赖时，会导致数十次的重新编译过程。

搜了下，发现 webpack 可追溯的 issue 记录为 Files created right before watching starts make watching go into a loop

该问题不论你是在使用 webpack-dev-middleware 或者 webpack --watch 又或者 webpack-dev-server 都可以复现。

webpack 作者 @sokra 对其解释为:

The watching may loop in a unlucky case, but this should not result in a different compilation hash. I. e. the webpack-dev-server doesn't trigger a update if the hash is equal.

白话理解为：确实有问题，但是呢，最关键的 compilation hash 不会变，所以上层使用时，自己内部处理下这个逻辑。

但实际情况呢， webpack-dev-server 等作者不认这一说！

粗暴的解决方案

至于不想刨根问底，这里也有狗皮膏药的解决方案：

// Webpack startup recompilation fix. Remove when @sokra fixes the bug.
// https://github.com/webpack/webpack/issues/2983
// https://github.com/webpack/watchpack/issues/25
const timefix = 11000;
compiler.plugin('watch-run', (watching, callback) => {
  watching.startTime += timefix;
  callback()
});
compiler.plugin('done', (stats) => {
  stats.startTime -= timefix
})

刨根问底

当然狗皮膏药并不是本文的重点，刚好借此一窥，webpack 中整体的 watch 机制。

如果不想看那么多代码片段，也可以看我在梳理代码逻辑时做的笔记，笔记中红色流程为初始化时的调用链路，蓝色部分为文件变更后事件回调链路。

首先我们可以确定一点的是，不管是 webpack 自身的 cli 工具还是 webpack-dev-middleware 和 webpack-dev-server 都是通过 Compiler.prototype.watch 来实现了 watch 的功能，进而来实现调试阶段的高性能需求。

为了比较清晰的知道整一个流程，我们从创建一个 Compiler 实例开始说起

webpack Compiler 实例的创建

总所周知我们通过 const compiler = webpack(webpackConfig); 这种方式来创建一个 Compiler 的实例，一般也叫做 webpack 的实例，compiler 实例对象中包含着和打包相关的所有参数，plugins loaders 等等。这种情况下 webpack 并不会默认进行构建编译的过程，如果想要启动编译则需要执行一下 compiler.run(callback)。 另外我们也可以通过 webpack(webpackConfig, callback); 默认来启动构建编译流程。

对于今天我们想要了解的 watch 过程我们这边只需要知道，当构建参数中含有明确开启 watch 配置项时整个流程的走向是 compiler.watch(watchOptions, callback); 而非 compiler.run(callback);。

题外话: 或许你比较好奇 compilation 是什么，它包含着 chunks modules 等信息，构建依赖文件变更时都会重新生成 compilation，而 compiler 只有一个。

源码追溯

compiler.watch 中创建 watch 服务

// compiler 的 watch 方法
class Compiler extends Tapable {
  watch(watchOptions, handler) {
    ...
    const watching = new Watching(this, watchOptions, handler);
		return watching;
  }
}

// Watch 类
class Watching {
	constructor(compiler, watchOptions, handler) {
		this.startTime = null;
		...
		this.compiler = compiler;
		this.compiler.readRecords(err => {
			if(err) return this._done(err);

			this._go();
		});
	}
}

在这边需要注意的是 startTime 每次编译执行时 _go 方法将被调用，调用时会赋值编译启动时间，该时刻在认定文件是否需要再次编译或者是否变更时非常非常重要！

源码追溯 1 源码追溯 2

首次编译初始化

当如上 this._go() 被执行时，即开始了首次的编译过程

_go() {
	this.startTime = Date.now();
	this.running = true;
	this.invalid = false;
	this.compiler.applyPluginsAsync("watch-run", this, err => {
		if(err) return this._done(err);
		const onCompiled = (err, compilation) => {
		  ...
		  this.compiler.emitAssets(compilation, err => {
		    ...
		    return this._done(null, compilation);
		  });
		};
		this.compiler.compile(onCompiled);
	});
}

敲黑板: 注意此时 startTime 被正式赋值为 首次构建编译开始的时间，同时 compile 的执行标志着首次编译的开始。

此次文章并不会涉及 webpack 的事件流，以及编译过程中 loaders 和 plugins 等的流转过程，这边我们只需要知道，执行 compile 后进入了编译流程即可。

由代码可以看出在正常流程下正常编译流程完毕后，调用 _done 方法。

_done(err, compilation) {
  ...
	const stats = compilation ? this._getStats(compilation) : null;
  ...
	this.compiler.applyPlugins("done", stats);
	...
	if(!this.closed) {
		this.watch(compilation.fileDependencies, compilation.contextDependencies, compilation.missingDependencies);
	}
}

在 compilation 对象中我们可以获取到和构建相关所有的依赖，而这些依赖正是需要去监听的内容。

源码追溯

正式开启文件监听

上个过程中我们可以看到最后我们把构建依赖，传递给了 watch 的方法。

watch(files, dirs, missing) {
	this.pausedWatcher = null;
	this.watcher = this.compiler.watchFileSystem.watch(files, dirs, missing, this.startTime, this.watchOptions, (err, filesModified, contextModified, missingModified, fileTimestamps, contextTimestamps) => {
		...
		this.invalidate();
	}, (fileName, changeTime) => {
		this.compiler.applyPlugins("invalid", fileName, changeTime);
	});
}

这里我们注意到 watch 实际调用的是 compiler.watchFileSystem.watch。看过源码的可能会很好奇，因为在 Compiler 的源码中没有定义过这个原型链上的方法。原因很简单，因为在 webpack(webpackConfig) 的阶段中，webpack 注入很多内部的自有插件，webpack 源码非常让人值得学习的一点就是插件机制应用的炉火纯青。具体我们可以看到这 webpack.js，而通过这个线索我们找到了NodeEnvironmentPlugin，开始有所眉目我们看到了熟悉的 watch 字眼 NodeWatchFileSystem，通过它进而我们终于找到了 NodeWatchFileSystem 兴奋之余 watch 服务最终的启动者 watchpack 也浮出水面。

题外话： 这边比较有趣的是 NodeEnvironmentPlugin 这个 plugin，在这个 plugin 中默认设置了 NodeOutputFileSystem NodeJsInputFileSystem CachedInputFileSystem，以 NodeOutputFileSystem 为例，在 webpack 默认情况下编译完成后文件内容都会通过 io 输出到实际的文件目录中，但是毕竟涉及 io 操作这种性能并不能满足调试的需求，所以在 webpack-dev-middleware 中会将 NodeOutputFileSystem 原本默认的 fs 替换为 memory-fs 进而 boost performance。另外 CachedInputFileSystem 等也是通过本地构建的缓存文件物理加速。由于这些内容并不是本文重点，所以不再展开，有兴趣的同学可以继续深挖。

const Watchpack = require("watchpack");

class NodeWatchFileSystem {
	constructor(inputFileSystem) {
		this.inputFileSystem = inputFileSystem;
		this.watcherOptions = {
			aggregateTimeout: 0
		};
		this.watcher = new Watchpack(this.watcherOptions);
	}
	watch(files, dirs, missing, startTime, options, callback, callbackUndelayed) {
	  ...
	  const oldWatcher = this.watcher;
		this.watcher = new Watchpack(options);
		...
		if(callbackUndelayed)
			this.watcher.once("change", callbackUndelayed);
		this.watcher.once("aggregated", (changes, removals) => {
		  ...
		  const times = this.watcher.getTimes();
			callback(null,
				changes.filter(file => files.indexOf(file) >= 0).sort(),
				changes.filter(file => dirs.indexOf(file) >= 0).sort(),
				changes.filter(file => missing.indexOf(file) >= 0).sort(), times, times);
    });
    ...
    this.watcher.watch(files.concat(missing), dirs.concat(missing), startTime);

		if(oldWatcher) {
			oldWatcher.close();
		}
		...
	}
}

基于 webpack 的源码不难发现最终 watch 交由的是 Watchpack 实例的 watch 方法。

接下来我们看到

Watchpack.prototype.watch = function watch(files, directories, startTime) {
	this.paused = false;
	var oldFileWatchers = this.fileWatchers;
	var oldDirWatchers = this.dirWatchers;
	this.fileWatchers = files.map(function(file) {
		return this._fileWatcher(file, watcherManager.watchFile(file, this.watcherOptions, startTime));
	}, this);
	this.dirWatchers = directories.map(function(dir) {
		return this._dirWatcher(dir, watcherManager.watchDirectory(dir, this.watcherOptions, startTime));
	}, this);
	oldFileWatchers.forEach(function(w) {
		w.close();
	}, this);
	oldDirWatchers.forEach(function(w) {
		w.close();
	}, this);
};

这边对 webpack 不是很熟悉的同学可能会比较困惑为什么 file 和 dir 需要进行区分 watch，默认情况下，通过 webpack resolve 后我们能拿到每个模块精确的路径地址，但是在一些特别的用法下，比如使用 require.context(path) 就会对该 path 所对应的目录加以监听。

所以在一般业务场景下只会涉及到 this._fileWatcher。

Watchpack.prototype._fileWatcher = function _fileWatcher(file, watcher) {
	watcher.on("change", function(mtime, type) {
		this._onChange(file, mtime, file, type);
	}.bind(this));
	watcher.on("remove", function(type) {
		this._onRemove(file, file, type);
	}.bind(this));
	return watcher;
};

根据如上代码我们可以获知 watcherManager.watchFile(file, this.watcherOptions, startTime) 返回了 一个 watcher
而 _fileWather 根本上是对返回的 watcher 做了一次事件绑定。

那我们看看 watcherManager.watchFile(file, this.watcherOptions, startTime) 到底创建了一个怎么样的 watcher。

WatcherManager.prototype.getDirectoryWatcher = function(directory, options) {
	var DirectoryWatcher = require("./DirectoryWatcher");
	options = options || {};
	var key = directory + " " + JSON.stringify(options);
	if(!this.directoryWatchers[key]) {
		this.directoryWatchers[key] = new DirectoryWatcher(directory, options);
		this.directoryWatchers[key].on("closed", function() {
			delete this.directoryWatchers[key];
		}.bind(this));
	}
	return this.directoryWatchers[key];
};

WatcherManager.prototype.watchFile = function watchFile(p, options, startTime) {
	var directory = path.dirname(p);
	return this.getDirectoryWatcher(directory, options).watch(p, startTime);
};

WatcherManager.prototype.watchDirectory = function watchDirectory(directory, options, startTime) {
	return this.getDirectoryWatcher(directory, options).watch(directory, startTime);
};

Step1: this.getDirectoryWatcher(directory, options)
如上所知不管是传入的内容是 file 路径还是 directory 路径，都会被转到 getDirectoryWatcher

言下之意就是一个目录下所有的文件都会被对应到一个 directoryWatcher。

在新建一个 DirectoryWatcher 的实例时

function DirectoryWatcher(directoryPath, options) {
	EventEmitter.call(this);
	this.options = options;
	this.path = directoryPath;
	this.files = Object.create(null);
	this.directories = Object.create(null);
	this.watcher = chokidar.watch(directoryPath, {
		ignoreInitial: true,
		persistent: true,
		followSymlinks: false,
		depth: 0,
		atomic: false,
		alwaysStat: true,
		ignorePermissionErrors: true,
		ignored: options.ignored,
		usePolling: options.poll ? true : undefined,
		interval: typeof options.poll === "number" ? options.poll : undefined
	});
	this.watcher.on("add", this.onFileAdded.bind(this));
	this.watcher.on("addDir", this.onDirectoryAdded.bind(this));
	this.watcher.on("change", this.onChange.bind(this));
	this.watcher.on("unlink", this.onFileUnlinked.bind(this));
	this.watcher.on("unlinkDir", this.onDirectoryUnlinked.bind(this));
	this.watcher.on("error", this.onWatcherError.bind(this));
	this.initialScan = true;
	this.nestedWatching = false;
	this.initialScanRemoved = [];
	this.doInitialScan();
	this.watchers = Object.create(null);
}

可以发现，webpack watch 文件夹变更的能力实际输出者为 chokidar
并且对 directoryPath 对应的 chokidar watcher，绑定 add，addDir， change，unlink，unlinkDir，error 等事件。
并执行了 this.doInitialScan();。

DirectoryWatcher.prototype.doInitialScan = function doInitialScan() {
	fs.readdir(this.path, function(err, items) {
		if(err) {
			this.initialScan = false;
			return;
		}
		async.forEach(items, function(item, callback) {
			var itemPath = path.join(this.path, item);
			fs.stat(itemPath, function(err2, stat) {
				if(!this.initialScan) return;
				if(err2) {
					callback();
					return;
				}
				if(stat.isFile()) {
					if(!this.files[itemPath])
						this.setFileTime(itemPath, +stat.mtime, true);
				} else if(stat.isDirectory()) {
					if(!this.directories[itemPath])
						this.setDirectory(itemPath, true, true);
				}
				callback();
			}.bind(this));
		}.bind(this), function() {
			this.initialScan = false;
			this.initialScanRemoved = null;
		}.bind(this));
	}.bind(this));
};

根据如上代码我们可以获知，在执行首次扫描时，会把当前文件夹下的内容读取出来。对文件则进行 this.setFileTime(itemPath, +stat.mtime, true);

这边不对 setFileTime 做过多阐述，他有两种使用场景。

一种来源于 initialScan 会把所有的文件的最新修改时间全部读取出来，为之后判断文件变更触发更新提供依据。另外一个场景就是触发更新了。

Step2: directoryWatcher.watch((p, startTime))

DirectoryWatcher.prototype.watch = function watch(filePath, startTime) {
	this.watchers[withoutCase(filePath)] = this.watchers[withoutCase(filePath)] || [];
	this.refs++;
	var watcher = new Watcher(this, filePath, startTime);
	watcher.on("closed", function() {
		var idx = this.watchers[withoutCase(filePath)].indexOf(watcher);
		this.watchers[withoutCase(filePath)].splice(idx, 1);
		if(this.watchers[withoutCase(filePath)].length === 0) {
			delete this.watchers[withoutCase(filePath)];
			if(this.path === filePath)
				this.setNestedWatching(false);
		}
		if(--this.refs <= 0)
			this.close();
	}.bind(this));
	this.watchers[withoutCase(filePath)].push(watcher);
	var data;
	if(filePath === this.path) {
		this.setNestedWatching(true);
		data = false;
		Object.keys(this.files).forEach(function(file) {
			var d = this.files[file];
			if(!data)
				data = d;
			else
				data = [Math.max(data[0], d[0]), Math.max(data[1], d[1])];
		}, this);
	} else {
		data = this.files[filePath];
	}
	process.nextTick(function() {
		if(data) {
			var ts = data[0] === data[1] ? data[0] + FS_ACCURACY : data[0];
			if(ts >= startTime)
				watcher.emit("change", data[1]);
		} else if(this.initialScan && this.initialScanRemoved.indexOf(filePath) >= 0) {
			watcher.emit("remove");
		}
	}.bind(this));
	return watcher;
};

该代码记录了一个 filepath 创建一个 Watcher 的过程，最后返回了该 wathcer。

所以再反观

Watchpack.prototype._fileWatcher = function _fileWatcher(file, watcher) {
	watcher.on("change", function(mtime, type) {
		this._onChange(file, mtime, file, type);
	}.bind(this));
	watcher.on("remove", function(type) {
		this._onRemove(file, file, type);
	}.bind(this));
	return watcher;
};

我们就可以知道，这边是对每个文件绑定了一个 change 和 remove 事件。

文件发生变更后，最初会被 directoryWatcher 监听到，进而触发对应的 fileWatcher 的 change 事件。

而 _onChange 会被调用

Watchpack.prototype._onChange = function _onChange(item, mtime, file) {
	file = file || item;
	this.mtimes[file] = mtime;
	if(this.paused) return;
	this.emit("change", file, mtime);
	if(this.aggregateTimeout)
		clearTimeout(this.aggregateTimeout);
	if(this.aggregatedChanges.indexOf(item) < 0)
		this.aggregatedChanges.push(item);
	this.aggregateTimeout = setTimeout(this._onTimeout, this.options.aggregateTimeout);
};

进而触发了 Watchpack 实例的 change 事件, 该事件由在 NodeWatchFileSystem 中绑定。

// 片段
if(callbackUndelayed)
	this.watcher.once("change", callbackUndelayed);

this.watcher.once("aggregated", (changes, removals) => {
	changes = changes.concat(removals);
	if(this.inputFileSystem && this.inputFileSystem.purge) {
		this.inputFileSystem.purge(changes);
	}
	const times = this.watcher.getTimes();
	callback(null,
		changes.filter(file => files.indexOf(file) >= 0).sort(),
		changes.filter(file => dirs.indexOf(file) >= 0).sort(),
		changes.filter(file => missing.indexOf(file) >= 0).sort(), times, times);
});

那如何触发重编译呢？答案在 aggregated 事件中。

function example(err, filesModified, contextModified, missingModified, fileTimestamps, contextTimestamps) => {
		this.pausedWatcher = this.watcher;
		this.watcher = null;
		if(err) return this.handler(err);

		this.compiler.fileTimestamps = fileTimestamps;
		this.compiler.contextTimestamps = contextTimestamps;
		this.invalidate();
}

触发 invalidate 事件，因为 _go 事件再次被执行。

invalidate(callback) {
	if(callback) {
		this.callbacks.push(callback);
	}
	if(this.watcher) {
		this.pausedWatcher = this.watcher;
		this.watcher.pause();
		this.watcher = null;
	}
	if(this.running) {
		this.invalid = true;
		return false;
	} else {
		this._go();
	}
}

之前我们的网红 @sorrycc 说可以把自己在用的软件和硬件分享出来，爽快答应后发现都拖了快一年了， ORZ。

所以这是一篇还债贴，所以这几天趁着午休和晚上整理了下。

以下是我日常工作和生活中的一些装备，和 cc 不太一样的是，我一旦习惯了某个东西，基本不会去变更。

编辑器和 Terminal

• 我的编辑器是 webstorm，最初受惠于 seajs 的开源分到了 jetbrains 赠予的一年免费使用权，到现在也算是一个忠实的付费用户了，用 webstorm 的主要原因是内置功能很强大，不必花心思去找很多辅助性插件，虽然有时真的还蛮卡的，但也真心希望它越来越好，所以给官方提过不少个 bug。辅助用的话 Sublime 是首选，当然偶尔也会打开下 vscode。
• XCode 不用多解释了，Apple 相关开发必备
• JSON Accelerator JSON 快速编辑
• Terminal 我用 iTerm2 + zsh + oh-my-zsh 的组合
• 使用 Operator Mono 字体 - 这是我们 cc 大哥力荐的，当然我也觉得非常好看，所以基本需要的地方都配了 Operator Mono
• 使用 nvm 来管理 node 版本，这在本地多版本测试时比较有用
• 使用 homebrew 来安装 macos 没有预装的软件包

翻墙

• 路由器翻墙用 google 云，绑信用卡一年免费，主要结合 Apple TV 看 Amazon Prime 和 YouTube 不稳定已经放弃，目前使用独立的硬件，自己 DIY 改造的，服务和 iOS，Android，Mac 通用
• 非家庭网络时用 surge 以及对应的 pro 服务 600 一年最近好像涨价到 900 了太贵了已经放弃
• 选择了 rixCloud，600 一年，机场已经跑路，现使用如有需要私信，也是 近 600 一年
• iPhone 和 Mac 都使用 surge iPhone 上使用了 shadowRocket，需要美区账号；Android 上我用了 Clash；Mac 上使用了 Surge(shadowRocket 也可以，只是 Surge 更符合开发人员)，当然也有免费的 ss
• 命令行下翻墙使用 Proxifier, 不知道为什么就是比使用 export 方式快很多

开发辅助

• SourceTree，git 辅助，因为记不住 git 高级命令 gui 带来了很大的便利
• Charles，抓包，支持 https，现在也会用 surge
• Paw，请求模拟
• Beyond Compare，文本文件比对
• Reveal，iOS 界面调试利器

在线应用

• Refiddle，调正则表达式
• ASTExplorer，调 ast
• IFTTT，applet 可以接很多智能家居用品，也可以串联很多工具流

文档

• Quiver，Markdown 笔记软件，界面朴素功能纯粹。
• 系统备忘录，能方便在 iOS 设备和 mac 设备间同步，适合需要速记的场景。
• keynote，对外分享时必选项

效率

• Alfred，应用的快速启动，以及 Code Snippet 管理，cc 教的
• 系统提醒事项，单纯的 todo list 可以用在生活中也可以用在工作中
• LICEcap ，GIF 录屏工具，可以调整帧率操作演示利器
• XMind: ZEN，流程图必选

影音

• movist 播放下载影片
• Softorino YouTube Converter，YouTube 视频下载
• Apple TV 4K 港版，配合全屋 (F)(Q) 感觉很棒，油管 + Netflix 是我生活必不可少的调味剂，值
• Bowers & Wilkins Zeppelin Wireless Air 齐柏林飞艇 3 代音箱，其实效果挺一般的，那会儿也没有试听，略后悔，不值
• 耳机 1：Beats Monster Pro，我是上一代的，塑化严重，皮接触汗水会烂，不值
• 耳机 2：Apple AirPods，我是上一代的，和 Apple 生态配合度高，但续航不符合我整体听歌的人，不值
• 耳机 3：Sony XBA N3AP，如果原先只是用手机附送耳机，那提升还挺明显的，但是听久了会觉得过于单薄，不值
• 耳机 4：Beyerdynamic XELENTO REMOTE，真的太棒了！值
• 音乐播放器：A&K SR15，听音乐的提升还是非常的，人声会比较前置，有种他在你边上唱歌给你听的感觉，当然是配合好的耳机，可以装 Android 的应用，那就解禁 QQ 音乐等一众 APP 了，但音源质量跟不上，好的音源很难找，基本找不到，所以会陷入到放弃。不值

设计

• sketch，视觉稿输出

系统

• Clean My Mac Mac 系统清理
• IStatmenus 系统右上角菜单增强与美化

其他

• 1Password，密码管理，记得在 mac app store 购买，那样子就可以有 iCloud 功能进行与手机端数据库同步

Chrome 插件

• Earth View from Google Earth 新开 tab 页时可以看到不一样的世界
• Redux DevTools 调试 react 应用必备
• React Developer Tools 调试 react 应用必备
• Proxy SwitchyOmega 快捷地管理和切换多个代理设置，可实现在线页面本地调试
• OctoLinker，对 github 中 require 或 import 的模块快速跳转
• Refined Github，Github 改进，包括样式、布局等
• SourceGraph for Github，源码跳转
• Tampermonkey，通过脚本来定制化某网页行为
• 1Password 1Password 在 chrome 端扩展
• Instapaper 实现信息流管理中的一环
• 惠惠助手 购物助手，可以查看历史价格

个人信息流管理

Mac: Instapaper -> IFTTT -> Github Private Repo
Mobile: Workflow -> Instapaper -> IFTTT -> Github Private Repo

所以的内容都会最后都会被归总到个人的 github 上的 private repo 的 issue，issue 的好处就不用多说。

硬件

• 弱电箱路由器 UBNT Edgerouter ER-X，路由器翻墙在此实现，值
• 吸顶无线路由器 UBNT UAP-AC-PRO，企业级稳定性民用级的价格，真心推荐 值
• MacBook Pro (Retina, 15-inch, Mid 2015)，日常使用，coding 无碍，但想要做视频基本可以放弃了，4k，H265 真心会卡爆 不值 升级为 Apple M1 Pro 高配，都挺好，建议内存升级到最大，这样做视频更游刃有余
• IMac 5K 自选顶配，剪辑 4k H265 还是卡啊！劝大家直接上 IMac Pro！总体觉得像是买了个屏幕！不值
• Lacie 2big dock 20t，算是桌面很棒的存储方案了，值
• iPhone X 港版，便宜又可享受保修 值
• PS4 港版，最爱游戏 使命召唤 神秘海域，目前基本已被闲置，使用率太低了， 不值
• SONY A1 55，显示效果真的没话说，不过 sony 出新一代的 OLED 电视了，建议购买新款，值

摄影相关

• 无人机 1：DJI Phantom 3 Pro，由于体积和画质问题已被淘汰做装饰，不值
• 无人机 2： DJI Mavic 2 Pro，真的太好用了，避障功能已经拯救了我多次，另外哈苏相机的画质真的超级好，app 功能越来越强大了，必须点赞！值
• 三脚架 1：捷信 1545T，不说别的，颜值绝对在线，但是 G-Lock 还是太麻烦了，虽然可以反折但是收纳能力还是差，另外比其他脚架真的重很多，不值
• 三脚架 2：JOBY 3K 400克自重承重6斤，vlog 必备 值
• 运动相机：GoPro 7 Black，轻巧方便，防抖收音佳，在户外运动拍摄时，值，但是对画质有追求的想拿来当 vlog 相机的，在我多次尝试后，我放弃了
• 360 相机：Insta 360 onex，360 还是挺酷的，另外配合官方的一些创意教学，还是值得入手买一个玩一下的，值
• 风光相机：SONY A7R2，目前该相机已经被我淘汰，虽然照片素质在线，但我现在主要拍视频，R2 视频对焦能力垃圾到爆，SLOG2 也实在无力吐槽，在各方面比对，以及实际拍摄体验后，就在今天我换了 a7m3，总体来说你要 拍照值，视频不值
• 视频相机：SONY A7M3 全面支持 HLG 和 mavic 2 pro 可以无风色彩衔接，好到爆的视频对焦能力，拍照和视频都值
• sony 系镜头：买过 16-35 F4 / 16-35 F2.8 / 85 F1.4 / 24 F1.4，目前 16-35 F4 和 85 已经被淘汰，留了 16-35 24 GM，又可以视频，又可以风光和银河，完美符合我的需求，16-35 F2.8 最值
• 人文数码相机：LEICA MP240，一般挂机镜头现行版 11663 35/1.4, leica 习惯把 1.4 的叫做 summilux Leica M-System 值
• 人文胶片相机：LEICA M7， 一般挂机镜头四代德产月牙 11819 50/2，该镜头是老头，已经没得卖了，现行版在此， leica 习惯把 2.0 的叫做 summicron，M7 真的太好用了，A 档真的太省事了，千万不要被说服去买 MA 或者 MP，这是忠告！ M7 值
• 风光滤镜 1：配合 SONY 使用，采用插片方案，使用LEE Big Stopper 100x100 和 GND 0.9 软， Lee Filter，b格是上线的，但是这巨大暗角也是感人的，不值
• Leica 滤镜：ND 镜，偏色严重，不值
• 视频滤镜 2：Peter Mckinnon Combo Set，非常棒 值
• 胶卷：因为喜好黑白，所以胶片大都使用 Ilford PAN 400，最细腻的话要给 JCH，彩色的话首推 柯达 Ektar 100， 但千万不要为了外包装好看而买一堆！值
• 照片打印机：Canon Pro-500，打印效果没的说，但是耗材贵到家，还占巨大的位置，有打印需求还是找机构吧，不值
• 照片打印纸：哈内姆勒 Hahnemuhle Photo Rag Satin 钟爱这款艺术纸，值
• 视频灯光系统 1： FalconEyes SO-68TD，偏色严重， 不值
• 视频灯光系统 2： Aputure 120D II，我们做过非常详细的对比测试，这款灯真的值到爆，值
• 照片灯光系统 1： SONY 闪光灯 SONY HVL F60M 素质很高，但基本闲置，偶尔一用， 不值
• 照片灯光系统2：Profoto B2 location kit + air TTL，闲置到电池报废， 不值
• 补光灯光：Aputure M9，体积小巧，可以加色片，灯光正 值

Arduino 相关

• Arduino Board 开源电子原型平台，创客圈最火的板子，可以开发出很多创新性互动装置
• Raspberry Pi Model B+ Board 树莓派微型电脑，功能强大，价格低廉，现在把它做为家庭的智能中枢
• Intel Edison Arduino Kit 大厂板子，做工一流，但 Intel 在 IoT 的投入纯属玩票
• Bare Conductive Touch Board 静电容量感应相关的板子，比较适合做隔空操作的相关有趣的事情
• Fritzing 布线图
• Real VNC 可视化控制操作一台远程电脑，比如 raspberry

推荐两家目前国内做的比较好的 dfrobot Seeed Studio

国外的话有 Sparkfun Adafruit

智能家居

• 米家智能家庭套装 价格低廉又好用
• Nest 英版管理地暖，需自己安装需要动强电，近期价格冰点可入手
• Home Connect 产品 如洗衣机 干衣机等

日常

• Rhodia 笔记本
• IFIXIT IFixIt 修理套装，由于我购买的比较早，所以我那一款已经下架了，如有兴趣可以择好而入。

小车车

• 爆改大脚怪牧马人 Rubicon

图片来自 New wave modularity with Lerna, monorepos, and npm organizations

前纪： 大概在 16 年初通过 babel 了解到了 lerna，同时也首次听到了 monorepo 这个概念。当时测试后的结果是，lerna 非常不稳定所以那会儿并没有使用。时隔近一年，在最近尝试中感觉各方面都做的不错了，所以已经开始在项目内使用。大概 google 了下国内似乎并没有文章介绍这一块内容，所以这篇文章的动力遍来源于此。

什么是 monorepo ?

Monorepo is a unified source code repository used by an organisation to host as much of its code as possible.

Monorepo 它是一种管理 organisation 代码的方式，在这种方式下会摒弃原先一个 module 一个 repo 的方式，取而代之的是把所有的 modules 都放在一个 repo 内来管理。

目前诸如 Babel, React, Angular, Ember, Meteor, Jest 等等都采用了 Monorepo 这种方式来进行源码的管理。

什么是 lerna ?

Lerna 它是基于 Monorepo 理念在工具端的实现。

lerna 出现的历史背景

Lerna 出现的历史背景，其实就是 Monorepos 和 Multirepos 在进行项目管理时优与劣。

说说我个人的感触：

Multirepos

缺点：

• 在 Multirepos 方案中我们通常一个项目会有一个 repo 或者说是一个 module 一个 repo，事实上因为项目或者 module 因为功能或者属性或者历史的原因我们不得不拆分到不同的 organisation 中，这导致了后期如果涉及人员交接，或者自己项目管理时就会陷入到不知道哪里去找 repo 的境地。（这个问题对于涉及历史包袱的开发会特别痛苦）

• issue 不知道往哪里提，导致项目管理混乱。（目前 atool-build、dora 都有这样的困境）

• 版本管理带来的日常开销，首先不得不说采用 semver 后确实给版本管理带来了很多便利之处，但是其偏向于于 patch 版本，当 core module 需要 发布 minor 或者 Major 版本时这就会变成一场灾难。举个例子，dora （插件化 server）的 core 需要变更时，我们得同步所有官方插件，这涉及到了 20 多个仓库，这完全是体力劳动。于此同时，在日常开发中，可能我们一次迭代会涉及多个 repo，一方面需要用 npm link 的方式 hack 到本地仓库，另外一方面，每次都需要手动切换到对应的各个仓库进行 lint test 等操作，要完成这些我们不得不在 terminal 中开启多个 tab，这绝对是个眼力和体力活

• changelog 梳理又是一场灾难，在 Multirepos 管理项目的情况下，我们需要人工同步所有变动的仓库最终列出一个 changelog。如果全部是由一个人开发还能理得清楚，但实际上一般正常迭代都是多人开发协同开发的模式，这个情况下我们很难统计到仓库依赖的 module 是否有更新，做了什么样的工作。

等等。

使用 monorepo 以上问题都可以迎刃而解。

但使用 monorepo 方案也有相应的缺陷

• 单个 repo 体积较大
• ？？

以上只是个人的一些项目中的感触，也来看看 babel 为什么选择 monorepo Why is Babel a monorepo

如何用 lerna 进行项目管理

step 1:

$ npm install --global lerna

step 2:

$ git init monorepo-example
$ cd monorepo-example

step 3:

$ lerna init

运行完后在 terminal 中执行 tree 后我们可以看到此时的目录结构为

$ monorepo-example git:(master) ✗ tree
.
├── lerna.json
└── package.json

step 4:

$ monorepo-example git:(master) ✗ mkdir packages && cd packages

创建 packages 目录，该目录内将会存放之后所有的官方维护的 module

step 5:

$  packages git:(master) ✗ mkdir monorepo-example-module-a && cd monorepo-example-module-a && npm init

$  packages git:(master) ✗ mkdir monorepo-example-module-core && cd monorepo-example-module-core && npm init

新建两个 package，并通过 npm init 来初始化 package.json

此时我们的 packages 目录结构为

➜  packages git:(master) ✗ tree
.
├── monorepo-example-module-a
│   └── package.json
└── monorepo-example-module-core
    └── package.json

假设 module-a 依赖 module-core 详细参考 monorepo-example 案例

step 6:

$ monorepo-example git:(master) ✗ lerna bootstrap
Lerna v2.0.0-beta.31
Bootstrapping 2 packages
Preinstalling packages
Installing external dependencies
Symlinking packages and binaries
Postinstalling packages
Prepublishing packages
Successfully bootstrapped 2 packages.

执行 lerna bootstrap 该操作会自动为 module-a 进行 npm install 和 npm link 操作. 如图

是不是非常方便呢！

step 7:

$  monorepo-example git:(master) lerna publish
Lerna v2.0.0-beta.31
Current version: 0.0.0
Checking for updated packages...
? Select a new version (currently 0.0.0) Patch (0.0.1)

Changes:
- monorepo-example-module-a: 0.0.1 => 0.0.1
- monorepo-example-module-core: 1.0.0 => 0.0.1

? Are you sure you want to publish the above changes? Yes

Publishing packages to npm...
npm WARN dist-tag add latest is already set to version 0.0.1
monorepo-example-module-a                          
npm WARN dist-tag add latest is already set to version 0.0.1
Pushing tags to git...

To [email protected]:pigcan/monorepo-example.git
   0f8674c..2ecb064  master -> master
To [email protected]:pigcan/monorepo-example.git
 * [new tag]         v0.0.1 -> v0.0.1
Successfully published:
 - [email protected]
 - [email protected]

执行 lerna publish 回答几个问题便可以把自己的包推送到 npm.

当然实际情况使用中，会更复杂一些，更多的内容就留给大家看官方使用说明了，基本都是简单明了的内容，如果有不清楚的地方欢迎大家提问 官方文档 commands

利用 lerna-changelog 来进行 changelog 的生成

在现实开发中我们经常碰到一个老大难的问题就是 changelog 的梳理，在 lerna 中提供了一个非常有用的 lerna-changelog 的库，在一定的规范开发下会使得这个问题解决起来非常方便，在这边以这个仓库为例我给大家大概讲解下如何使用。

step 1:

$ monorepo-example git:(master) npm install lerna-changelog --save-dev

安装 lerna-changelog 依赖

step 2:

修改 lerna.josn 需要新增相关 lerna-changelog 所需要的配置

+"changelog": {
+  "repo": "pigcan/monorepo-example",
+  "labels": {
+    "tag: bugfix": "Bug fix",
+    "tag: enhancement": "Enhancement"
+  },
+  "cacheDir": ".changelog"
+}

在这边需要特别注意的是 labels 内的内容，labels 的 key 必须在 github 的仓库内定义好

可以通过以下链接 https://github.com/pigcan/monorepo-example/labels 来进行 labels 的创建，接下来我在 github 上分别新增 tag: bugfix 和 tag: enhancement

step 3:

$ export GITHUB_AUTH="..."

GITHUB_AUTH 的 token 字段可以在github 申请 token 获得。

步骤到此结束了，但是这边要想要达到理想的效果必须要遵循一定的开发规则，其实就是需要有好的开发习惯，在此推荐个人的习惯。

如案例所示 https://github.com/pigcan/monorepo-example/issues 把项目碰到的 bug、需要增强的地方等等内容都记入到 issue中，并标记好相应的 label 标签。

创建对应的分支，来解决对应 issue 中记入的内容。

$  monorepo-example git:(bugfix-core) git branch
* bugfix-core
  enhance-module-a
  master

例如我们在此修复 core 的问题，最终 commit 的日志推荐为

$ git commit -a -m "core-bugfix: the xxx problem had fixed, Close #1"

在 commit 的 message 中要把解决了什么问题和相应的 issue 进行关联，然后一目了然，如果后续需要对该部分代码进行回滚也会变得非常轻松。

一旦 bugfix-core 分支被提交后，我们可以在 github 上以该分支创建一个 pr ，

在创建 pr 时需要注意 ** 一定要选择对应的 label ** 在这个案例中我需要选择，tag: bugfix

具体可以参考 soda-x/monorepo-example#3

一旦分支的代码合并到主干后本地运行

$  monorepo-example git:(master) node_modules/.bin/lerna-changelog

## Unreleased (2017-01-05)

#### Bug fix
* `monorepo-example-module-core`
  * [#3](https://github.com/pigcan/monorepo-example/pull/3) core-bugfix: the xxx problem had fixed, Closes [#1](https://github.com/pigcan/monorepo-example/issues/1). ([@pigcan](https://github.com/pigcan))

#### Committers: 1
- pigcan ([pigcan](https://github.com/pigcan))

看是不是已经生成了绝妙的 changelog 日志。

在需要 publish 之前我们运行一次 lerna-changelog 以便拿到日志（publish 后之前的 commit 信息将会被清空）

一旦 publish 后我们便可以创建 release note https://github.com/pigcan/monorepo-example/releases

以下便是最终的效果，是不是很酷很方便呢！

Refs

• lerna
• lerna-changelog
• The Case for Monorepos
• Advantages of monolithic version control
• New wave modularity with Lerna, monorepos, and npm organizations
• Monorepo, scaling projects

最近一周在补前人留下的测试用例，然后碰到了一个 sinon 的使用问题困扰了一整天，特做此记录。

文章的前提是：你对 sinon 已经有了初步的使用经验。

// src.js
function add(a, b) {
  return a + b;
}

function multiplication(a, b) {
  return a * b;
}

export function complex(a, b) {
  console.error('此处为 error 发生出');
  return add(a, b) + multiplication(a, b);
}

export default function division(a, b) {
  return add(a, b)/multiplication(a, b);
}

//test.js
import test from 'ava'; // eslint-disable-line
import sinon from 'sinon'; // eslint-disable-line

import { complex }, division from '../src';

let sandbox;


test.before(() => {
  sandbox = sinon.sandbox.create();
});

test.after(() => {
  sandbox.restore();
});

test('complex', (t) => {
  sandbox.stub(console, 'error');
  // how to stub add or multiplication ?
});

碰到第一个问题是：如何 stub 非 export 的方法呢 ？另外 stub 的 api 要求，method 需要挂载在相应的
object 下

无奈之下我选择了最偷懒的方式把 add 和 multiplication 都修改为 export 的方法，使用了 import * 的方式

即修改为了

// src.js
export function add(a, b) {
  return a + b;
}

export function multiplication(a, b) {
  return a * b;
}

export function complex(a, b) {
  console.error('此处为 error 发生出');
  return add(a, b) + multiplication(a, b);
}

export default function division(a, b) {
  return add(a, b)/multiplication(a, b);
}

//test.js
import test from 'ava'; // eslint-disable-line
import sinon from 'sinon'; // eslint-disable-line

import * as math  from '../src';

let sandbox;

test.before(() => {
  sandbox = sinon.sandbox.create();
});

test.after(() => {
  sandbox.restore();
});

test('complex', (t) => {
  sandbox.stub(console, 'error');
  sandbox.stub(math, 'add').returns(2);
  sandbox.stub(math, 'multiplication').returns(3);
  t.true(console.error.called);
  t.is(math.complex(2, 3), 5);
  // 用例挂了 t.is(11, 5);
});

偷懒方式破灭，发现 math.complex(2, 3) 返回的是 11，也就是 stub math add 和 multiplication 并没有生效！但是关键是 console.error 被正常改写。到底发生了什么！所以我猜想 stub 的 add 和 multiplication 方法并不是 complex 方式调用的 add 和 multiplication

由于并不清楚发生了什么，所以猜测是不是因为引用关系的问题

所以我开始尝试，改写 src.js 尽量保证引用关系

let math;

function add(a, b) {
  return a + b;
}

function multiplication(a, b) {
  return a * b;
}

function complex(a, b) {
  console.error('此处为 error 发生出');
  process.exit(1);
  return math.add(a, b) + math.multiplication(a, b);
}

math = {
  add,
  multiplication,
  complex,
};

export { math };

然而答案居然是成功了！！！！但回过头必须要思考的事情是：1.这种处理方案并不完美，原因在于为了写测试需要变更源码本身相对优雅的写法，同时会暴露无关的内部函数 2. 为什么 直接 export 到具体的 function 不行，但是 export 到 对象就行了，这或许并不是引用关系的问题。

带着这个思考，我往这个方向 google 了下，非常有意思我发现了在 stackoverflow 上的提问 https://stackoverflow.com/questions/35240469/how-to-mock-the-imports-of-an-es6-module

其中在非常不显眼的地方我居然看到了问题最最最关键的内容，

@carpeliam This wont work with the ES6 module spec where the imports are readonly.

import 的内容是 readonly 的！！！！！！！但是其内部 child 不是 readonly 的！！！！！！！至此豁然开朗！！！！

接下来我就开始想，如果说这是因为 spec 的原因导致，那么万能的 babel 解决这个问题肯定易如反掌，所以我开始尝试搜索这方面的 babel-plugin 。结果当然是 wala babel-plugin-rewire

因为找对了方向，所以问题的解决方式也越合规。其中认为最合适的是how to stub ES6 module dependencies。

最佳实践

// src.js 不需要对 源码 文件作出任何的调整
function add(a, b) {
  return a + b;
}

function multiplication(a, b) {
  return a * b;
}

export function complex(a, b) {
  console.error('此处为 error 发生出');
  return add(a, b) + multiplication(a, b);
}

export default function division(a, b) {
  return add(a, b)/multiplication(a, b);
}

import test from 'ava'; // eslint-disable-line
import sinon from 'sinon'; // eslint-disable-line

import * as math from '../src';

let sandbox;

const rewire = (module, methodName, method) => {
  module.__Rewire__(methodName, method);

  return method;
};

test.before(() => {
  sandbox = sinon.sandbox.create();
});

test.after(() => {
  sandbox.restore();
});

test('complex', (t) => {
  sandbox.stub(console, 'error');
  rewire(math, 'add', sandbox.stub())
    .returns(2);
  rewire(math, 'multiplication', sandbox.stub())
    .returns(3);

  t.true(console.error.called);
  t.is(math.complex(2, 3), 5);
});

补充课外题

当如果 src.js 中我们 import 了 一个 util 的方法

// src.js

import { chalk } from 'util';

export default function log() {
  console.log(chalk.yellow('yellow log'));
}

请问如何测试 chalk.yellow 被正确调用了？

TLDR;

教条一：不管是 html 元素还是 body 元素，它们都是透明的。
教条二：如需全局背景色，请将背景色设置于 body 元素上。
教条三：UI Library 作者需要设置元素的背景色，同时最好在 body 元素上设置好基调色。
教条四：习惯设置背景色是个好习惯，嗯，你是个好孩子

既然事情总结的如此简单，那还有必要专门写一篇文章吗？！ 答案是：有，经过测试这里还有不少坑

名词解释

Riddle: 一个前端代码片段分享平台，支持但不限于 React 代码的在线编辑和演示，当前 Riddle 演示功能的实现依托于嵌入的 Gravity iframe，即 Riddle 加载到实例代码后会发消息给 Gravity，而 Gravity 会通过约定的消息拿到代码后开始编译，并加载对应的入口文件，最终由 Gravity 实现预览。

Gravity: 基于浏览器技术的 bundless 方案。

背景

前一阵子，Riddle 联合 CloudIDE 的第一期合作发布，其中有一项变更是将原先的 Light 模式升级到了 Dark 模式。升级之后遭到了用户的投诉，原因是 Dark 模式影响了他们的展现。

起先我是感到委屈的，因为非常确定在完成编译之后我没有给嵌入的 iframe 设置颜色。第一反应就是，难道 HTML 默认是透明的，不是白色的？！内心飘过三个字。

出了问题肯定是要刨根问底的，那接下来就是弄明白时间。

探索

探索第一步：验证是透明的，并尽可能遍历应用场景防再踩坑

编写测试案例。

注明：
Body区域： Body 以内，后简写为 B
HTML区域： HTML 以内，后简写为 H
ViewPort区域： 整个可视区域，后简写为 V
Drag区域： 由拖拽而展现出来的区域(通常是页面的最上端和最下端由于拖拽而展现区域)，后简写为 D

过程一: 单一 html

(1) 没有设置背景色 html-none-body-none
(2) html 未设置背景色 body 设置红色 html-none-body-red
(3) html 设置黄色 body 未设置颜色 html-yellow-body-none
(4) html 设置黄色 body 设置红色 html-yellow-body-red

直接进入总结环节：

这里我们发现

1. body 的颜色优先级为 body -> html
2. html 的颜色优先级为 html -> body
3. viewport 的颜色优先级为 html -> body
4. drag 区域颜色在同时设置 html 和 body 背景色时存在兼容性问题。 如果移动为先的思路，优先级应该是 body > html

过程二 - 嵌套 iframe

讨论完了第一 p，那我们再来看看第二 p，嵌套 iframe 也是一种非常常见的场景

注明：以下颜色记录均为 iframe

(1) html-none-body-none 嵌套 html-none-body-none 的 iframe
(2) html-none-body-red 嵌套 html-none-body-none 的 iframe
(3) html-none-body-none 嵌套 html-yellow-body-red 的 iframe

综合第一 P，这里我们发现：

1. html，body，viewport，drag 区域默认是透明的
2. iframe 中的 drag 区域是透明的，这里和 1 中有差别

过程三 - 嵌套 iframe 的疑惑表现

这里产生困惑，iframe 区域的 drag 区域如何设置颜色呢

(1) html-none-body-none 嵌套 html-yellow-body-red 的 iframe，且设置 iframe 的 background-color: green

从此可以得出

iframe 的 drag 区域颜色由 iframe 的颜色决定，当未设定时，其就是透明的。

过程四 - background-color 和 background-image 之间的影响

(1) html 设置黄色和图梵高星空 body 设置红色和图梵高睡莲 html-yellow-image（记为星）-body-red-image（记为莲）

(2) 嵌套场景 html-none-body-none/html-yellow-星-body-red-莲

注明：以下颜色记录均为 iframe

从此可以得出

1. 当设置 background-image 时，兼容性问题依旧存在，html 的优先级为 html > body，body 的优先级为 body > html
2. viewport 区域的的优先级为 html > body，这里的意思是如果未对 html 做相关背景色或者背景图设置，viewport 的将被 body 的 html 颜色或者背景图填充
3. 嵌套模式下，drag 区域依旧为透明色
4. 由于存在兼容性问题需要谨慎设置背景图平铺

探索第三步：W3C 求理论

在做完上面的探索之后，其实内心有了个想法就是想要确定下，我们的标准到底是怎么样的。

于是我在 W3C 上找到了一些答案 -》 W3C

The document canvas is the infinite surface over which the document is rendered.

If the canvas background is not opaque, the canvas surface below it shows through. The texture of the canvas surface is UA-dependent (but is typically an opaque white).

The background of the root element becomes the canvas background and its background painting area extends to cover the entire canvas. However, any images are sized and positioned relative to the root element as if they were painted for that element alone. (In other words, the background positioning area is determined as for the root element.) The root element does not paint this background again, i.e., the used value of its background is transparent.

For documents whose root element is an HTML HTML element or an XHTML html element [HTML]: if the computed value of background-image on the root element is none and its background-color is transparent, user agents must instead propagate the computed values of the background properties from that element’s first HTML BODY or XHTML body child element. The used values of that BODY element’s background properties are their initial values, and the propagated values are treated as if they were specified on the root element. It is recommended that authors of HTML documents specify the canvas background for the BODY element rather than the HTML element.

这里其实可以总结为一个图：

但是这里要表达的是 W3C 制定的标准和浏览器厂商的实现是有一定的差距的，这里存在不少兼容性的问题。同时如果认真把文章读下来，或者有认真比对 DEMO 展现的话，这里其实有一个很迷的东西（viewport），这个概念在 W3C 的表述里是不存在的，在标准中更加倾向于把 viewport 理解为 canvas ，但是我们在测试过程中能比较明显感觉到 canvas 的表现并不能简简单单的把 viewport 画上等号 （典型案例：在移动端 html-yellow-body-red，如果我们限制了 html 元素的高度，但是可视区域依旧是会被渲染为黄色，但是可拖拽区显示为红色，这就非常不符合 canvas 层的定义，反而 chrome 的 pc 端反而更加符合标准）。

乱入 CSS 属性 mix-blend-mode

在翻阅资料的时候，看到了一个有趣的且容易掉坑的 CSS 属性 - mix-blend-mode，该CSS 属性描述了元素的内容应该与元素的直系父元素的内容和元素的背景如何混合。

这里为了说明问题，我们就讲一个 mix-blend-mode: difference，difference 的意思是取反，即反色。举例我们现在有一个色彩 色值为 rgb(255, 0, 255)，紫色，那它在白色的反色就是 rgb(0, 255, 0) 绿色。

  .div {color: rgb(255, 0, 255);mix-blend-mode: difference;font-weight: bold;font-size: 30px}

  <div class="div">文字颜色</div>

这里其实我们预期的是得到的是 粉，因为背景色为透明色，而 chrome 移动 Safari 桌面 Safari 移动显然是以白色为基础的反色了。

嵌套 iframe

注明一下颜色为，iframe 内文字颜色

这里和上诉单纯的 html 一比较发现存在的差异，iframe 中的文字清一色的变为了粉色。

综上总结：

- mix-blend-mode: difference 兼容性存在很大的问题，甚至存在 position 的设定也会影响具体的表现。那如何避免呢，方案很简单，对自己所需的元素设置背景色，不要依赖外界。

如何设置浏览器底色

Firefox 可以很轻松设置，CMD + ,，相信你可以很快找到。

为什么会有这种需求呢，我想了下，确实有这种场景，比如现在的 Dark Mode 并没有真正意义上的实现 Dark Mode，因为我们没法控制软件层的底色，根据这次测试来看，即使你操作系统设置了 Dark Mode，但是你的软件的背景色还是白色。所以在一些特殊场景下，你还是能看到那个白。

这里也衍生出了一种网站设计的流派，原先我也不太清楚，那就是透明派，比如 vimeo。我觉得初衷是好的，因为他们想要尊重用户的选择（我猜的），但是事实上，这绝对不是一个明智的方式，因为用户的偏好很可能违背你的设计（假设设计设计了 Light Mode，正常黑色字体，而如果用户偏好 Dark Mode，那么用户就啥也看不到了），因此我对透明的制作思路保留我自己的看法。

总结

教条一：不管是 html 元素还是 body 元素，它们都是透明的。
教条二：如需全局背景色，请将背景色设置于 body 元素上。
教条三：UI Library 作者需要设置元素的背景色，同时最好在 body 元素上设置好基调色。
教条四：习惯设置背景色是个好习惯，嗯，你是个好孩子

以下是所有的测试 demo

test.zip

同步一篇旧文，下文中的 Gravity 指的是浏览器的 Bundless 方案，可在 D2 分享 - 基于浏览器的实时构建探索之路 中找到相应的内容

之前犯了一个认知的错误，卡了很久，分享给大家.

在 webpack 中 less 文件可以通过 import 的方式引入三方样式文件，该样式文件可以是 npm 库中的文件(@import "~npm/a.css")，或者本地文件(@import "relative/to/a.less")。

这里我认知出错的地方是： 以为 less-loader 可以处理所有 import 的文件 （less-loader 本质是一个 附加了 webpack resolve 逻辑的 less plugin），即我原认为 less-loader 处理完之后是一个完全可用的 css 文件（事实不是如此）。

我的卡点就是： Gravity 中尝试实现 import npm 库发现，当我 @import "~npm/a.css" 时，less plugin 的 resolve 逻辑怎么都不会进入到我的自定义 resolve 逻辑中来（能注册成功插件，却不执行插件）。

恍然大悟的点是： 在 less 的设计中，不会对 css 文件做任何的处理，包括自定义插件，除非把 less 提供的 reference 强制把 css 设置为 less，即（@import (less) "~npm/a.css"），这种方式是强侵入性的，和 webpack 的方式相比需要我们感知更多的开发工具细节。 到目前我觉得 less 这一块设计是可以优化的，让插件开发者来决定是否走插件的逻辑，而不是现在的注册一个插件默认认定为是应用给 less 的，如果需要给该 css 应用 less 插件逻辑，得硬编码，这绝对不是面向用户的解决方式。
后来我发现，webpack 这一块处理是交给 css-loader 的， 即 less-loader 处理完 import less 逻辑后，其并不会处理 import css 逻辑，而 import css 逻辑交给了 css-loader 中的 postcss 去分析 import 的语法，再做进一步处理。

解决方案：
在 Gravity 中引入 postcss-loader

即实现链路 less-loader -> postcss-loader -> style-loader

如何基于 webpack 做持久化缓存似乎一直处于没有最佳实践的状态。网路上各式各样的文章很多，open 的 bug 反馈和建议成堆，很容易让人迷茫和心智崩溃。

作为开发者最大的诉求是：在 entry 内部内容未发生变更的情况下构建之后也能稳定不变。

TL;DR;

拉到最后看总结 XD

hash 的两种计算方式

想要做持久化缓存的首要一步是 hash，在 webpack 中提供了两种方式，hash 和 chunkhash

在此或许有不少同学就这两者之间的差别就模糊了：

hash：在 webpack 一次构建中会产生一个 compilation 对象，该 hash 值是对 compilation 内所有的内容计算而来的，

chunkhash：每一个 chunk 都根据自身的内容计算而来。

单从上诉描述来看，chunkhash 应该在持久化缓存中更为有效。

到底是否如此呢，接下来我们设定一个应用场景。

设定场景

• hash 计算方式为 hash 时：

......
module.exports = {
  entry: {
    "pageA": "./a.js",
    "pageB": "./b.js",
  },
  output: {
    path: path.join(cwd, 'dist'),
    filename: '[name]-[hash].js'
  },
  module: {
    rules: ...
  },
  plugins: [
    new ExtractTextPlugin('[name]-[hash].css'),
  ]
}

构建结果：

Hash: 7ee8fcb953c70a896294
Version: webpack 3.8.1
Time: 6308ms
                         Asset       Size  Chunks                    Chunk Names
 pageB-7ee8fcb953c70a896294.js     525 kB       0  [emitted]  [big]  pageB
 pageA-7ee8fcb953c70a896294.js     525 kB       1  [emitted]  [big]  pageA
pageA-7ee8fcb953c70a896294.css  147 bytes       1  [emitted]         pageA
pageB-7ee8fcb953c70a896294.css  150 bytes       0  [emitted]         pageB

如果细心一点，多尝试几次，可以发现即使在全部内容未变动的情况下 hash 值也会发生变更，原因在于我们使用了 extract，extract 本身涉及到异步的抽取流程，所以在生成 assets 资源时存在了不确定性（先后顺序），而 updateHash 则对其敏感，所以就出现了如上所说的 hash 异动的情况。另外所有 assets 资源的 hash 值保持一致，这对于所有资源的持久化缓存来说并没有深远的意义。

• hash 计算方式为 chunkhash 时：

......
module.exports = {
  entry: {
    "pageA": "./a.js",
    "pageB": "./b.js",
  },
  output: {
    path: path.join(cwd, 'dist'),
    filename: '[name]-[chunkhash].js'
  },
  module: {
    rules: ...
  },
  plugins: [
    new ExtractTextPlugin('[name]-[chunkhash].css'),
  ]
}

构建结果：

Hash: 1b432b2e0ea7c80439ff
Version: webpack 3.8.1
Time: 1069ms
                         Asset       Size  Chunks                    Chunk Names
 pageB-58011d1656e7b568204e.js     525 kB       0  [emitted]  [big]  pageB
 pageA-5c744cecf5ed9dd0feaf.js     525 kB       1  [emitted]  [big]  pageA
pageA-5c744cecf5ed9dd0feaf.css  147 bytes       1  [emitted]         pageA
pageB-58011d1656e7b568204e.css  150 bytes       0  [emitted]         pageB

此时可以发现，运行多少次，hash 的异动没有了，每个 entry 拥有了自己独一的 hash 值，细心的你或许会发现此时样式资源的 hash 值和 入口脚本保持了一致，这似乎并不符合我们的想法，冥冥之中告诉我们发生了某些坏事情。

然后尝试随意修改 b.css 然后重新构建得到以下日志，

Hash: 50abba81a316ad20f82a
Version: webpack 3.8.1
Time: 1595ms
                         Asset       Size  Chunks                    Chunk Names
 pageB-58011d1656e7b568204e.js     525 kB       0  [emitted]  [big]  pageB
 pageA-5c744cecf5ed9dd0feaf.js     525 kB       1  [emitted]  [big]  pageA
pageA-5c744cecf5ed9dd0feaf.css  147 bytes       1  [emitted]         pageA
pageB-58011d1656e7b568204e.css  147 bytes       0  [emitted]         pageB

不可思议的恐怖的事情发生了，居然 PageB 脚本和样式的 hash 值均未发生改变。为什么？细想一下不难理解，因为在 webpack 中所有的内容都视为 js 的一部分，而当构建发生，extract 生效后，样式被抽离出 entry chunk，此时对于 entry chunk 来说其本身并未发生改变，因为改变的部分已经被抽离变成 normal chunk，而 chunkhash 是根据 chunk 内容而来，所以不变更应该是符合预期的行为。虽然原理和结果符合预期，但是这并不是持久化缓存所需要的。幸运的是，extract-text-plugin 为抽离出来的内容提供了 contenthash 即： new ExtractTextPlugin('[name]-[contenthash].css')

Hash: 50abba81a316ad20f82a
Version: webpack 3.8.1
Time: 1177ms
                                     Asset       Size  Chunks                    Chunk Names
             pageB-58011d1656e7b568204e.js     525 kB       0  [emitted]  [big]  pageB
             pageA-5c744cecf5ed9dd0feaf.js     525 kB       1  [emitted]  [big]  pageA
pageA-3ebfe4559258be46a13401ec147e4012.css  147 bytes       1  [emitted]         pageA
pageB-c584acc56d4dd7606ab09eb7b3bd5e9f.css  147 bytes       0  [emitted]         pageB

此时我们再修改 b.css 然后重新构建得到以下日志，

Hash: 08c8682f823ef6f0d661
Version: webpack 3.8.1
Time: 1313ms
                                     Asset       Size  Chunks                    Chunk Names
             pageB-58011d1656e7b568204e.js     525 kB       0  [emitted]  [big]  pageB
             pageA-5c744cecf5ed9dd0feaf.js     525 kB       1  [emitted]  [big]  pageA
pageA-3ebfe4559258be46a13401ec147e4012.css  147 bytes       1  [emitted]         pageA
pageB-0651d43f16a9b34b4b38459143ac5dd8.css  150 bytes       0  [emitted]         pageB

很棒！一切符合预期，只有 pageB 的样式 hash 发生了变更。你以为事情都结束了，然而总是会一波三折

接下来我们尝试在 a.js 中除去依赖 a.less，再进行一次构建，得到以下日志

Hash: 649f27b36d142e5e39cc
Version: webpack 3.8.1
Time: 1557ms
                                     Asset       Size  Chunks                    Chunk Names
             pageB-0ca5aed30feb05b1a5e2.js     525 kB       0  [emitted]  [big]  pageB
             pageA-1a8ce6dcab969d4e4480.js     525 kB       1  [emitted]  [big]  pageA
pageA-f83ea969c4ec627cb92bea42f12b75d6.css   91 bytes       1  [emitted]         pageA
pageB-0651d43f16a9b34b4b38459143ac5dd8.css  150 bytes       0  [emitted]         pageB

奇怪的事情再次发生，这边我们可以理解 pageA 的脚本和样式发生变化。但是对于 pageB 的脚本也发生变化感觉并不符合预期。

所以我们 pageB.js 去看一看到底是什么发生了变更。

通过如下命令我们可以获知具体的变更位置

$ git diff dist/pageB-58011d1656e7b568204e.js dist/pageB-0ca5aed30feb05b1a5e2.js

结果为：

 /******/       __webpack_require__.p = "";
 /******/
 /******/       // Load entry module and return exports
-/******/       return __webpack_require__(__webpack_require__.s = 75);
+/******/       return __webpack_require__(__webpack_require__.s = 74);
 /******/ })
 /************************************************************************/
 /******/ ([

/***/ }),
 /* 73 */,
-/* 74 */,
-/* 75 */
+/* 74 */
 /***/ (function(module, exports, __webpack_require__) {

 "use strict";


 console.log('bx');
-__webpack_require__(76);
+__webpack_require__(75);
 __webpack_require__(38);
 __webpack_require__(40);

 /***/ }),
-/* 76 */
+/* 75 */
 /***/ (function(module, exports) {

 // removed by extract-text-webpack-plugin

以上我们可以明确的知道，当 pageA 内移除 a.less 后整体的 id 发生了变更。那么可以推测的是 id 代表着具体的引用的模块。

其实在构建结束时，webpack 会给到我们具体的每个模块分配到的 id 。

case: pageA 移除 a.less 前

[73] ./a.js 93 bytes {1} [built]
[74] ./a.less 41 bytes {1} [built]
[75] ./b.js 94 bytes {0} [built]
[76] ./b.less 41 bytes {0} [built]

case: pageA 移除 a.less 后

[73] ./a.js 72 bytes {1} [built]
[74] ./b.js 94 bytes {0} [built]
[75] ./b.less 41 bytes {0} [built]

通过比较发现，在 pageA 移除 a.less 的依赖前，居然在其构建出来的代码中，隐藏着/* 73 */, 和 /* 74 */,，也就是说 pageB 的脚本中包含着 a.js, a.less 的模块 id 信息。这对于持久化来说并不符合预期。我们期待的是 pageB 中不会包含任何和它并不相关的内容。

这边衍生出两个命题

命题1：如何把不相关的 module id 或者说内容摒除在外

命题2：如何能让 module id 尽可能的保持不变

module id 异动

我们来一个一个看。

命题1：如何把不相关的 module id 或者说内容摒除在外

简单来说，我们的目标就是把这些不相关的内容摒除在 pageA 和 pageB 的 entry chunk 之外。

对 webpack 熟悉的人或多或少听说过 Code Splitting，本质上是对 chunk 进行拆分再组合的过程。那谁能完成此任务呢？

相信你已经猜到了 - CommonsChunkPlugin

接下来我们回退所有之前的变更。来检验我们的猜测是否正确。

在构建配置中我们加上 CommonsChunkPlugin

...
plugins: [
  new ExtractTextPlugin('[name]-[contenthash].css'),
+ new webpack.optimize.CommonsChunkPlugin({
+   name: 'runtime'
+ }),
],
...

case: pageA 移除 a.less 前

Hash: fc0f3a602209ca0adea9
Version: webpack 3.8.1
Time: 1182ms
                                       Asset       Size  Chunks                    Chunk Names
               pageB-ec1c1e788034e2312e56.js  316 bytes       0  [emitted]         pageB
               pageA-cd16b75b434f1ff41442.js  315 bytes       1  [emitted]         pageA
             runtime-3f77fc83f59d6c4208c4.js     529 kB       2  [emitted]  [big]  runtime
  pageA-8c3d50283e85cb98eafa5ed6a3432bab.css   56 bytes       1  [emitted]         pageA
  pageB-64db1330bc88b15e8c5ae69a711f8179.css   59 bytes       0  [emitted]         pageB
runtime-f83ea969c4ec627cb92bea42f12b75d6.css   91 bytes       2  [emitted]         runtime

case: pageA 移除 a.less 后

Hash: 8881467bf592ceb67696
Version: webpack 3.8.1
Time: 1185ms
                                       Asset       Size  Chunks                    Chunk Names
               pageB-8e3a2584840133ffc827.js  316 bytes       0  [emitted]         pageB
               pageA-a5d2ad06fbaf6a0e42e0.js  190 bytes       1  [emitted]         pageA
             runtime-f8bc79ce500737007969.js     529 kB       2  [emitted]  [big]  runtime
  pageB-64db1330bc88b15e8c5ae69a711f8179.css   59 bytes       0  [emitted]         pageB
runtime-f83ea969c4ec627cb92bea42f12b75d6.css   91 bytes       2  [emitted]         runtime

此时我们再通过如下命令

$ git diff dist/pageB-8e3a2584840133ffc827.js dist/pageB-ec1c1e788034e2312e56.js

对 pageB 的脚本来进行对比

 webpackJsonp([0],{

-/***/ 74:
+/***/ 75:
 /***/ (function(module, exports, __webpack_require__) {

 "use strict";


 console.log('bx');
-__webpack_require__(75);
+__webpack_require__(76);
 __webpack_require__(27);
 __webpack_require__(28);

 /***/ }),

-/***/ 75:
+/***/ 76:
 /***/ (function(module, exports) {

 // removed by extract-text-webpack-plugin

 /***/ })

-},[74]);
\ No newline at end of file
+},[75]);
\ No newline at end of file