Day_06 : 让 Vite 来开启你的Vue 之 Production Build

Hi Dai Gei Ho~ 我是Winnie～

今天是中秋连假的第一天，（而听主管说 通常连假什麽的最容易在铁人赛中殒落XD）， 所以为了证明我还没殒落，希望大家今天还有看到我的第六篇文章 XD

回到正题，在昨天的文章中，我们比较了 常见打包工具（Webpack） 与 Vite 各自的 dev-server(本地服务器) 特点与 运作模式 。 但後来在夜深人静时 我才惊觉自己没说到关於 Vite 的 Production Build 运作方式XDD，所以在今天的主题将 补充於上篇，来说说 Vite 的 Production Build。

Vite 的 Production Build

与 Vite 开发环境使用 原生ESM 运作模式 的不同， 在Production的环境下，Vite与 webpack 一样，也就是采取 传统Bundle的方式来进行 编译压缩档案， 所以 当我们 在终端机下 yarn build 时，也就会发现在dist资料夹中的 index.js也是一大包，所有哩哩叩叩的程序码都会在里面。

文章说到这边～ 你可能会想问 那为什麽不使用 Native ESM 呢？

针对这个问题，Vite在官方文件中也做了解释：

Vite does utilize bundling for production builds, because native ES module imports result in waterfall network requests that are simply too punishing for page load time in production.

大致意思是说，虽然目前 Native ESM 得到了浏览器 广泛的支援，但因为 模组之间的import 会产生 一大串的模组引入 依赖链。因此也就造成 浏览器 就必须等这些模组全部 下载 完後才能开始执行档案，而当依赖链很长串 对 浏览器而言就很容易造成依赖过载等待时间过长 的问题，而这就是 上述官方文件所说 waterfall network requests。

一大串依赖链是什麽？

简单来说就像上图一样，一台超长联结车，车头连结A车厢，而A厢又必须连结B车厢，就这样一直连啊连，最後产生的一串很长的依赖链。而你今天要开这台联结车的话，到达目的地就会花费很久时间，而 模组引入的依赖链 也是这样的意思。

所以至少现在对於 Vite来说 Native ESM 目前还是 不太适合 使用在 production 的环境下，但也不难保证未来可以解决这个问题，因为其实已经有套件开始试着在解决了XD。

Vite 使用的 Build 工具

再公布 Vite 使用哪个 Build 工具之前，我们先来看看 尤雨溪大大 与 Webpack创办人的对话

对的，很明显XD，Vite不是使用Webpack来进行打包，而是使用 rollup。

为什麽选择 Rollup呢？

事情是这样的，由於 Vite主要还是以 原生ESM为主的前端建构工具，而在选择打包工具时可能也是希望可以选择 基於原生ESM的打包工具。

而刚好Rollup就符合此需求，不仅是基於ES2015的打包工具，而最大特色还可以透过较快的时间来将档案打包成更小容量。

然後我们再从 以下rollup.config.js来看看

// rollup.config.js
import babel from 'rollup-plugin-babel';

export default {
    input: './src/index.js',
    output: {
        file: './dist/bundle.rollup.js',
        format: 'cjs'
    },
    plugins: [
        babel({
            presets: [
                [
                    'es2015', {
                        modules: false
                    }
                ]
            ]
        })
    ]
}

从上程序码们可以看出，Rollup 使用起来十分简洁，config 使用的是ESM同时 可以支持相对路径的写法。

因此综合以上优点，Vite 选择了Rollup。

最後 谢谢大家的阅读 以上是今天的文章。