Vue之项目整合与优化 alias 入口收敛与 Gzip 压缩

项目跑到第三个月，代码里开始出现 import HelloWorld from '../../../../HelloWorld.vue' 这种东西；多页应用的三个入口文件长得几乎一模一样，加一行埋点要改三处；打包出来的 app.js 五百多 KB，弱网下白屏时间长得能泡杯茶。这三件事都不算大问题，但堆在一起就是每天在消耗你。这篇讲三个投入产出比很高的整理动作，路径别名、入口配置收敛、Gzip 压缩，每个都是改一次以后一直受益。

在本篇文章中，我们将从浅入深，和大家一起学习以下知识：

• 用 alias 把相对路径换成语义化前缀，以及 CLI 3 里为什么要走 chainWebpack
• 样式和 html 模板里引用别名为什么必须加 ~
• 多入口文件的重复初始化代码怎么抽成一个函数，一处修改多处生效
• CompressionWebpackPlugin 的四个关键参数，threshold 和 minRatio 各自在挡什么
• Gzip 生成的 .gz 文件要服务器配合才有意义，nginx 那边该开什么
• 这三件事在 Vite 时代对应的做法

# 一、使用 alias 简化路径

# 问题出在哪

使用 webpack 构建过 Vue 项目的同学应该知道 alias 的作用，我们可以使用它将复杂的文件路径定义成一个变量来访问。在不使用 alias 的项目中，我们引入文件的时候通常会去计算被引入文件对于引入它的文件的相对路径，比如像这样：

import HelloWorld from '../../../../HelloWorld.vue'

一旦相对层次结构较深，我们就很难去定位所引入文件的具体位置。其实这并不是我们应该操心的地方，完全可以交给 webpack 来进行处理。

相对路径真正的代价不在写的时候，在移动文件的时候。你把一个组件从 views/user/ 挪到 views/account/，里面所有的 ../../ 全部作废，而且编辑器不一定能全帮你改对，改漏一个就是运行时报错。

在原生的 webpack 配置中我们可以定义 alias 来解决这一问题：

const path = require('path')

const resolve = dir => {
    return path.join(__dirname, dir)
}

module.exports = {
    ...
    
    resolve: {
        alias: {
            '@': resolve('src'), // 定义 src 目录变量
            _lib: resolve('src/common'), // 定义 common 目录变量,
            _com: resolve('src/components'), // 定义 components 目录变量,
            _img: resolve('src/images'), // 定义 images 目录变量,
            _ser: resolve('src/services'), // 定义 services 目录变量,
        }
    },
    
    ...
}

上方我们在 webpack resolve（解析）对象下配置 alias 的值，将常用的一些路径赋值给了我们自定义的变量，这样我们便可以将第一个例子简化为：

import HelloWorld from '_com/HelloWorld.vue'

不管这个文件在哪一层，写法都一样。文件移动之后引用不用动，这才是别名的主要价值，少敲几个点号只是顺带的。

这里的命名用了 _lib、_com 这种下划线开头的短前缀，是为了和 npm 包名区分开。webpack 解析模块的时候，先在 alias 表里查，没命中才去 node_modules 找。前缀太普通的话，比如你定义了一个叫 utils 的别名，正好又装了一个叫 utils 的包，就会打架。@ 是 Vue CLI 默认就配好的 src 别名，可以直接用。

# CLI 3 里怎么改

而在 CLI 3.x 中我们无法直接操作 webpack 的配置文件，我们需要通过 chainWebpack 来进行间接修改，代码如下：

/* vue.config.js */
module.exports = {
    ...
    
    chainWebpack: config => {
        config.resolve.alias
            .set('@', resolve('src'))
            .set('_lib', resolve('src/common'))
            .set('_com', resolve('src/components'))
            .set('_img', resolve('src/images'))
            .set('_ser', resolve('src/services'))
    },
    
    ...
}

chainWebpack 和 configureWebpack 的分工值得说一句：后者是整块合并，适合加插件、改 entry 这类整体性的改动；前者基于 webpack-chain，能精确定位到某一条已有的 loader 规则去改它的某个参数，适合做外科手术。改 alias 用哪个都行，改「已有的 url-loader 的 limit 值」这种就只能用 chainWebpack。这两个口子的区别在多页配置里更明显，我在 Vue CLI3之pages 构建多页应用 里写过 configureWebpack 返回对象和原地修改的坑。

# 样式里要加波浪线

这样我们修改 webpack alias 来简化路径的优化就实现了。但是需要注意的是对于在样式及 html 模板中引用路径的简写时，前面需要加上 ~ 符，否则路径解析会失败，如：

.img {
    background: url(~_img/home.png);
}

原文这里写的是 background: (~_img/home.png)，少了 url()，这样写 CSS 是不生效的，我补上了。

那为什么在 CSS 里非要加个 ~ 呢？

因为 css-loader 处理 url() 的时候要先判断这是一个相对路径还是一个模块请求。看到 ./img/a.png 它当相对路径处理，看到 ~foo/a.png 它把 ~ 剥掉，剩下的部分交给 webpack 的模块解析流程，这时候 alias 才会生效。不加 ~，_img/home.png 会被当成当前文件旁边的一个叫 _img 的目录，自然找不到。

html 模板里通过 <img src="~_img/xxx.png"> 引用是同样的道理，走的是 vue-loader 对模板资源路径的转换。

# 二、整合功能模块

在多页应用的构建中，由于存在多个入口文件，因此会出现重复书写相同入口配置的情况，这样对于后期的修改和维护都不是特别友好，需要修改所有入口文件的相同配置。

比如在 index 单页的入口中我们引用了 VConsole 及 performance 的配置，同时在 Vue 实例上还添加了 $openRouter 方法：

import Vue from 'vue'
import App from './index.vue'
import router from './router'
import store from '@/store/'
import { Navigator } from '../../common'

// 如果是非线上环境，不加载 VConsole
if (process.env.NODE_ENV !== 'production') {
    var VConsole = require('vconsole/dist/vconsole.min.js');
    var vConsole = new VConsole();

    Vue.config.performance = true;
}

Vue.$openRouter = Vue.prototype.$openRouter = Navigator.openRouter;

new Vue({
  router,
  store,
  render: h => h(App)
}).$mount('#app')

这段代码里有两处细节。require 写在 if 里面而不是文件顶部，是为了让 VConsole 只在非生产环境被打进包里；如果写成顶部的 import，静态分析阶段就会把它作为依赖引入，生产包里也会带上这个几十 KB 的调试工具。Vue.config.performance = true 打开的是组件级别的性能追踪，开发时能在浏览器 Performance 面板里看到每个组件 init、compile、render、patch 各花了多少时间。这个开关在生产环境要关掉，它本身有开销。

$openRouter 是多页应用里跨单页跳转的封装，具体实现和为什么需要它，我在 Vue多页路由与模板解析 里写过。

而在 page1 和 page2 的入口文件中也同样进行了上述配置。那我们该如何整合这些重复代码，使其能够实现一次修改多处生效的功能呢？

最简单的方法便是封装成一个共用方法来进行调用。这里我们可以在 common 文件夹下新建 entryConfig 文件夹用于放置入口文件中公共配置的封装，封装代码如下：

import { Navigator } from '../index'

export default (Vue) => {

    // 如果是非线上环境，不加载 VConsole
    if (process.env.NODE_ENV !== 'production') {
        var VConsole = require('vconsole/dist/vconsole.min.js');
        var vConsole = new VConsole();

        Vue.config.performance = true;
    }

    Vue.$openRouter = Vue.prototype.$openRouter = Navigator.openRouter;
}

上述代码我们向外暴露了一个函数，在调用它的入口文件中传入 Vue 实例作为参数即可实现内部功能的共用。

注意这里是把 Vue 当参数传进来的，而不是在这个文件里自己 import Vue。这个选择挺重要：模块拿到的是入口文件里的那个 Vue 引用，挂在原型链上的东西一定作用在同一个 Vue 上。如果这个文件自己 import 一次，在某些构建配置下（比如 Vue 被配成了 external，或者存在多份 Vue 副本）就可能挂到另一个 Vue 上去，表现为「明明写了 $openRouter 却是 undefined」。这类问题查起来非常费劲。

我们可以将原本的入口文件简化为：

import Vue from 'vue'
import App from './index.vue'
import router from './router'
import store from '@/store/'
import entryConfig from '_lib/entryConfig/'

// 调用公共方法加载配置
entryConfig(Vue)

new Vue({
  router,
  store,
  render: h => h(App)
}).$mount('#app')

入口文件瘦下来了，而且瘦下来之后它读起来是有结构的：引依赖、装公共配置、创建实例挂载。以后要加全局指令、全局过滤器、错误上报，都往 entryConfig 里塞，三个入口文件一个字都不用动。

这个模式在单页项目里同样成立，只是收益没那么直观。单页只有一个 main.js，把配置抽出去主要是为了让入口保持干净，顺便让这部分逻辑可测试。