打包优化之Vite中external与globals的作用

属性的具体位置：

build.rollupOptions.external

build.rollupOptions.output.globals

使用场景：

先说external：

在组件库打包时，如果组件库支持按需加载，那就涉及到多入口打包，有时多个组件使用的是同一个第三方库，如果直接打包，结果如下：

可以看到，直接打包是可以用的，但每个组件都会打包一次'第三方lib'，增加了包的体积。

这个时候external就派上用场了，他能将第三方库分离出来，比如external: ['echarts']相当于声明打包的时候不要把echarts打包到项目中去，比如打包到 import * as echarts from 'echarts'语句的时候，就会停止，保留引用语句，不会将echarts的代码再打进来。

那到哪里找echarts的代码呢？

需要注意的是，我们在组件库中配置了external，导致打包的时候不会打进去echarts的代码，但是package.json中还是有echarts的依赖声明的，所以，在父项目引用我们的子系统的时候，会去安装echarts库。这样，在组件库代码运行到 import * as echarts from 'echarts'的时候，会去父项目的node_modules中寻找echarts，使得多个组件共用一个echarts库代码，减少了组件库的打包体积。

再来看globals：

基于上面的场景，我们回顾这句话：比如打包到 import * as echarts from 'echarts'语句的时候，就会停止，保留引用语句，不会将echarts的代码再打进来

可以提问，如果打包到import就停止了，是不是说明代码里有import ? 那如果打包的是iife模式或者umd模式，会如何处理？

答：是的，关于import的说法，只支持es模式的打包，如果按照iife或者umd的模式打包，不会存在import语句。iife，最后打包出来是一个自执行函数。umd最后打出来是一个支持 amd, cjs, iife的综合体。而amd和cjs都有自己的库引用方式（define和require），只有iife无法直接引用库名，那他是怎么处理库引用的呢，globals就是来解决这个问题的。

先看下iife的样子：

css 复制代码

(function(a,b){
    ...
})(c,d)

可以看到，iife与外界的沟通，就是通过参数传递的形式，globals的作用就是告诉编译器，打包出来的文件应该用什么参数调用第三方库。

看下globals的配置方式：

css 复制代码

rollupOptions: {
    ...
    output: {
        ...
        globals: {
            'echarts': 'myChartLib'
        }
    }
}

这样配置，就说明了，打包后的iife的代码中，所有用到echarts的地方，都是用myChartLib变量来使用的，比如:

javascript 复制代码

// 原来是
import * as echarts from 'echarts'
echarts.init(...)
// 打包后
(function(c,d) {
    ...
    myChartLib.init(...)
})(a,b)

在使用这个iife的包的项目中，就会需要一个全局变量myChartLib，才能使得iife的包能够正常运行。

再举个简单的例子：

某个iife打包模式下打出的第三方库用到了jQuery 配置的 'jQuery': '$'

业务系统想要正确的使用这个第三方库，就必须在第三方库调用前，引入jQuery，并保证能够通过$调用jQuery。