为何 webpack4 默认支持 ES6 语法的压缩？

在专栏课程里，有位同窗提到过一个颇有意思的问题：“我没装 babel，js 入口里写了个箭头函数，运行 webpack 构建命令后，也成功编译了。这是为何？”。今天就带领你们一块儿去探讨下这个话题。

在使用 webpack 的时候，很常见的一个构建优化手段就是缩小构建目标。好比在构建阶段只构建 src 里面的模块代码，对于 node_modules 里面所引入的三方包不进行构建操做。

发现问题

若是使用的是 webpack 3.x 版本，编写的构建脚本相似这样的，咱们经过设置loader 里面的 exclude 字段避免因为解析 node_modules 里面的模块形成的构建耗时：

const path = require('path');
const webpack = require('webpack');

module.exports = {
    entry: './src/index.js',
    output: {
        path: path.join(__dirname, 'dist'),
        filename: 'bundle.js'
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                loader: 'happypack/loader',
                exclude: path.join(__dirname, 'node_modules')
            }
        ]
    }
    plugins: [
        new webpack.optimize.UglifyJsPlugin()
    ]
};
复制代码

咱们常常会遇到一个问题，假设引入的 npm 包质量不够高，好比 node_modules 里面有 ES6 的语法，那么 webpack 在 uglify 阶段会报错！下面给出两种常见的出错场景：

ES6 的模板字符串

假设 node_modules 里面存在 ES6 的模板字符串语法，那么在生产环境打包的代码压缩阶段，UglifyJs 会抛出错误。

ES6 的箭头函数

一样的，你使用 ES6 的箭头函数也是没法正常的压缩代码的。

细心的你必定会发现若是使用的是 webpack 4，这个场景描述的问题将再也不出现。webpack 4默认支持 ES6 代码的压缩，这个是什么缘由呢？

初步分析

若是你有对 webpack 4 的依赖包进行过相关分析，好比直接查阅 package.json 文件或者经过 npm.broofa.com/ 网站上进行 webpack 依赖图分析。不难发现 webpack 4 里面使用了 terser-webpack-plugin 插件替代了以前一直使用的 uglifyjs-webpack-plugin 做为它的内置插件。

以 4.39.3 这个版本为例，能够看到它的 package.json 文件的依赖包括了terser-webpack-plugin。

咱们进一步分析发现 webpack 的 4.26.0 这个版本有一次提交，它的提交内容是对 webpack 内置插件进行了一次切换。

通过这么一次分析，咱们能够知道 webpack 4 之因此具有默认压缩 ES6 代码的能力，离不开 terser-webpack-plugin所起的做用！

进一步分析

在探究 terser-webpack-plugin 插件的原理前，咱们先系统的回顾一下代码压缩插件的历史：

• 当 uglifyjs-webpack-plugin 版本小于 v1.0 时，它使用的是 uglify-js 依赖
• 可是 uglify-js 并不支持 ES6, 所以在 uglify-js 仓库的 harmony 分支 Fork 了一个 uglify-es
• uglifyjs-webpack-plugin 的 v1.x 为了支持 ES6 的压缩语法，将 uglify-js 依赖切换到了 uglify-es
• 可是 uglify-es 中止维护了: mishoo/UglifyJS2#3156 (comment)
• uglify-es 的中止维护致使了 terser 被 fork 出来了，而且 terser 处理了没有合入的 PRs，最终建立了一个独立的仓库： github.com/fabiosantos…
• 随后，terser-webpack-plugin 被建立出来, 它基于 terser，而且具有uglifyjs-webpack-plugin 的同等功能 : github.com/webpack-con…
• 因为 uglifyjs-webpack-plugin v2.x 回退到了 uglify-js, 再也不支持 ES6。 所以那些但愿支持 ES6 语法压缩的项目必须切换到 terser-webpack-plugin

备注：压缩插件历史的来源 github.com/webpack/web…

到这里，咱们能够得出一个基本的结论：terser-webpack-plugin 基于 terser 所以它具有 ES6 的压缩能力，uglifyjs-webpack-plugin v2.x 版本基于 uglify-js，没法支持 ES6 的压缩。

插件	依赖	是否支持 ES6（Y/N）
terser-webpack-plugin	terser	Y
uglifyjs-webpack-plugin v1.x	uglify-es	Y
uglifyjs-webpack-plugin v2.x	uglify-js	N

原理探究

代码压缩原理其实挺简单的，也是 AST 的一个经典的应用案例。它的压缩过程一般是：

JS 源代码 -> AST -> 美化、压缩 -> 新的 AST -> 压缩后的代码 
复制代码

了解了代码压缩的基本流程后，接下来咱们看看源码包含了哪些内容，因为 terser 是从 uglify-es Fork 出来进行修改的，所以它的代码结构和 uglify-js 基本一致，只不过 terser 使用了 ES6 模块的静态分析功能。咱们以 terser 的源码为例分析下：

• ast.js：JS 的抽象语法树的描述信息
• parse.js：Parser，用于从 JS 源代码分析出 AST
• minify.js：用于将 AST 优化成更简短的结构
• output.js：代码生成器，从 AST 输出 压缩后的代码，支持 sourcemap 的生成
• propmangle.js：对变量的长度进行压缩，一般是单个字符
• scope.js：分析变量定义/引用位置的信息
• transform.js：节点遍历

而后，咱们来一探 terser 和 uglify-js 的差别。对比了以后，发现一个很大的差别是 AST 的支持上面不一样。

分析AST的差别发现，下面是两个文件 diff 对比只在 terser 中才有，而这些恰好对应 ES6 的语法。

AST_Arrow,
AST_Await,
AST_BigInt,
AST_Class,
AST_ClassExpression,
AST_ConciseMethod,
AST_Const,
AST_DefaultAssign,
AST_Destructuring,
AST_Expansion,
AST_Export,
AST_ForOf,
AST_Import,
AST_Let,
AST_NameMapping,
AST_NewTarget,
AST_PrefixedTemplateString,
AST_Super,
AST_SymbolMethod,
AST_TemplateSegment,
AST_TemplateString,
AST_Yield
复制代码

至此，咱们发现 webpack4 默认支持 ES6 压缩的关键是：terser 里面实现了 ES6 语法的 AST解析。

---

想学习更多 webpack 和前端工程相关知识能够扫码关注咱们团队同窗公众号：前期推送频率每周一篇。