精读《webpack4.0 升级指南》

本周精读的是 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.tsx

webpack.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

对应:

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 优化是什么,以及怎么做。

现代浏览器支持了以下两种语法:

<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 标签。这种方案最大缺陷是,如果用户不按照约定使用内置的 Linkprefetch 规则将会无效。

5 更多讨论

讨论地址是:精读《webpack4.0 升级指南》 · Issue #66 · dt-fe/weekly

如果你想参与讨论,请点击这里,每周都有新的主题,每周五发布。

上一篇:SAP上云的最佳技术实践


下一篇:ACK 云盘定时快照使用文档