本周精读的是 webpack4.0 一些变化，以及 typescript 该怎么做才能最大化利用 webpack4.0 的所有特性。
1 引言
前段时间尝试了 parcel 作为构建工具，就像农村人享受了都市的生活，就再也回不去了一样，发现无配置真是前端构建工具的大趋势，用起来非常方便快捷，再也不想碰 webpack 的配置了。
可是实践一段实践后，发现 parcel 还是不够成熟，主要体现在暂时不支持一些 rollup 优秀特性：Tree shaking、Scope Hoist，大型项目打包速度反而比 webpack3.0 慢。由于笔者完全零配置，当发现构建速度急速下降时，自然把矛头指向了 parcel :p.
就在前几周，webpack4.0 发布了，也拥抱了零配置，我想，是时候再回到 webpack 了。可是，文档好少，怎么迁移呢？
就在这几天，webpack 文档发布了 4.0 版本，虽然遗留了大量旧文档，不过也足够参考了。
2 精读
笔者尝试了 webpack node api，尝试了很久，发现被坑了。文档里只字未提 mode 模式，4.0 环境下 compiler 总是提示没有 mode 的 warning。
读了一些文档，发现 webpack4.0 大力度宣传的是 cli 方式启动，里面提到了最重要的 webpack --mode 模式，可见 webpack4.0 更推崇的是让开发者使用高度封装的 cli，而不是使用 node 方式开发（那 node 文档也应该更新呀）。笔者又看了一圈，发现 webpack-dev-server 的 webpack 版本升到了 4.0，ts-loader 也升级到了 4.0，可能生态已经全部准备好了。
使用 webpack cli、webpack-dev-server cli
安装 webpack^4.1.1 webpack-cli^2.0.10 webpack-dev-server^3.1.0，以及创建一个公共配置文件 webpack.config.ts:
export default {
entry,
output,
module: {
rules
},
resolve,
resolveLoader,
devServer: {
https: true,
open: true,
overlay: {
warnings: true,
errors: true
},
port
}
}记得用 tsc 转换为 webpack.config.js 作为 cli 入口。
开发模式下使用 webpack-dev-server:
webpack-dev-server --mode development --progress --hot --hotOnly --config ./webpack.config.js生产环境 build 使用 webpack:
webpack --mode production --progress --config ./webpack.config.js开发/生产模式，都以 webpack.config.ts 作为配置，其中 devServer 项仅在开发模式下，对 webpack-dev-server 生效。
一旦开启了 --mode production，会自动开启代码压缩、scope hoist 等插件，以及自动传递环境变量给 lib 包，所以已经不需要 plugins 这个配置项了。同理，开启了 --mode development 会自动开启 sourceMap 等开发插件，我们只要关心更简单的配置，这就是 4.0 零配置的重要改变。
mode=production,mode=development具体内置了哪些配置，可以参考这篇文章：webpack 4 终于知道「约定优于配置」了。恰恰有意思的是，webpack4 这么做，就是不想我们浪费时间了解这些机制，社区应该会慢慢习惯零配置的开发方式。
当然，虽然说零配置，但配置文件基本三板斧还是非常有必要配置：entry output module。
我们可能还要给配置文件传一些参数，比如定制多种开发模式的入口，通过 --env 传递：
webpack-dev-server --mode development --env.entry ./src/main.tsxwebpack.config.ts 接收：
const entry = yargs.argv.env.entry使用 typescript webpack
简单来说，只需要 ts-loader 就够了。在 webpack.config.ts 中增加新的 rules:
{
module: {
rules: [{
test: /.(tsx|ts)?$/,
use: ["ts-loader"]
}]
}
}注意 tsconfig.json 中模块解析策略使用： "module": "esnext"。
原因是 webpack 需要 es6 import 语句，才能进行 tree shaking 或者动态 import 优化，我们不再让 ts-loader 包办模块设置，换句话说，我们采用白名单方式看待 typescript 以及 babel，只让他做我们需要的工作，剩下的丢给 webpack 处理，可以获得最大程度性能优化。
如果仅使用 webpack typescript，建议将 ts 编译输出模式调整为 es3，因为 webpack 自带的压缩工具对 es6 语法还存在报错，而且也不会做兼容处理。
使用 typescript babel webpcak
注意处理顺序，ts -> babel -> webpack。
因为多出了 babel，我们将 ts 编译兼容模式关闭："target": "esnext"，模块也不要解析："module": "esnext"，ts-loader 仅仅将 typescript 代码转换成 js，其他一切优化都不要做，将 esnext 原生代码直接传给 babel 处理。
babel 这一层的职责是对代码进行兼容处理，不要压缩，也不要把 import 转成 require。笔者发现 babel 直接解析 import 代码会无法处理，因此需要 stage-2 preset:
{
presets: [
["env", {
modules: false,
}],
["stage-2"]
],
plugins: [
["transform-runtime"]
],
comments: true
}从上面配置可以看到，babel 这层对 esnext 的代码进行了浏览器兼容处理（env 插件），直接透传 import（stage-2 插件让 babel 识别 esModule），以及支持 async await（transform-runtime） 插件。
本来想用 env 替代 transform-runtime 的功能，笔者暂时没有查询到可行方式，欢迎读者补充。
另外要允许 babel 保留注释（comments: true），因为 webpack import 支持自定义 chunkName 是通过注释的方式：
import(/* webpackChunkName: "src" */ "./src")配合 react-loadable 使用更佳：
Loadable({
loader: () => import(/* webpackChunkName: "src" */ "./src"),
loading: (): any => null
})因为 react-loadable 让页面按 chunk 方式打包，而 webpack 又会自动 picke shared chunks，配合给每个 page chunks 通过 webpackChunkName 定义名称，webpack 可以给每个共享 chunks 更加可读的名字，比如：vendor~src,about,login，你就知道这个是 src about login 三个页面间公共模块。
可能已经有人看出瑕疵了，给每个文件增加 webpackChunkName 注释既麻烦又不优雅，而且只要有一个开发者没有加这个注释，上面说的可读 chunks 可能就缺少了某个模块名。
这就要笔者之前一篇精读来看了：精读《Rekit Studio》，项目可以通过约定的方式定义页面，入口文件通过 cli 自动生成，不就既减少业务代量，又统一加上了 webpackChunkName 嘛？
这里小小安利下集成了这个思路的项目脚手架 pri，使用了 ts babel webpack4.0，上述的小优化也是内置的功能之一。
webpack4 带来的是适配成本的大幅优化
社区似乎有部分声音在抱怨，webpack 又发新版本，我们又要适配一轮。其实 webpack 这么做恰恰没有带来适配成本，出问题的在于我们对 webpack 的使用方式与理念。
如果我们开始就将 webpack 当作一体化打包方案，开发调试使用 webpack-dev-server cli，开发环境编译使用 webpack cli，那么 webpack4 其实只是补充了开发环境这个最重要的配置变量而已。类比 parcel 的两个命令：
parcel index.html
parcel build index.html对应：
代码语言：javascript复制webpack-dev-server --mode development
webpack --mode production所以 webpack4 几乎是有史以来最方便使用与迁移的版本，前提是使用思维得正确，舍得将编译环节全权交给两个官方的 Cli。
3 总结
只要合理的使用 typescript、babel，让各自只发挥最小功能，将原生的模块化代码抛给 webpack，再配合 --mode production 配置，webpack 会自动开启一切可能的插件优化你的项目，而我们再不需要阅读形形色色的 webpack 插件了，更令人激动的是，随着 webpack 版本升级，优化会不断升级，而我们只要留着 --mode 参数，不需要改一行配置。
总结起来，就是不用关心优化相关的配置，我们只需要配置业务相关的 entry output module，这就是 webpack4.0.
我以前为了实现第一次编译完后立即打开浏览器的功能，写了一共 200 行的 customCompiler 以及 format-webpack-message，而且利用 koa 开了一个 server，利用 await 和 flags 等待第一次编译完的时机，并利用 opn 库打开网页。
其实用 cli 只需要 webpack-dev-server --open。
随着新的一波零配置浪潮，真的不应该在编译配置上花那么多时间了。
4 番外 - prefetch
读者自习阅读就会发现，这不是一篇单纯 webpack4 升级指南，仔细阅读可以发现文中蕴藏的一些工程优化思路。文章末尾再给一波福利，分析一下 prefetch 优化是什么，以及怎么做。
现代浏览器支持了以下两种语法：
代码语言：javascript复制<link rel="preload" />
<link rel="prefetch" />兼容性自己查 Caniuse，笔者重点在功能上。preload 收集当前用到的资源，prefetch 收集未来用到的资源。
页面本质上也是未来一种资源，如果认为用户会点击另一个页面（如果对产品没自信，或者 pv 过低可以忽略这个功能），就可以用 prefetch 让浏览器在空闲时间下载下一个页面的 chunk 文件。
前端包体积优化效率一般和用户体验是违背的，既然下一个页面在另一个 chunk 中，用户点击后必然会产生 loading。可是如果结合了 prefetch，鱼和熊掌就兼得了（正常用户不可能页面还没加载完就立刻点按钮跳页，所以唯一的缺点几乎不会对正常用户产生影响）。
api 有了，那么最大的问题就是，当前页面怎么知道要加载哪些 chunks？一般两种做法：
全量模式 使用比如 preload-webpack-plugin 插件，将所有生成的 chunk 都作为 prefetch 资源，在所有页面中。几乎所有规模的项目都不会产生过多的 chunks，所以这个方案理论上不够优雅，但能解决实际问题。
按需模式，是理论和实践双重优雅的方案，是否要这么做取决于您是否有代码洁癖。方法是提供一个定制的 Link 标签，根据 URL 地址按需生成 prefetch 标签。这种方案最大缺陷是，如果用户不按照约定使用内置的 Link，prefetch 规则将会无效。
5 更多讨论
讨论地址是：精读《webpack4.0 升级指南》 · Issue #66 · dt-fe/weekly
