探究前端项目打包构建的用户故事

“打包”——一个前端研发无比熟悉的词语，打包工具从来都不是必要，后端（nodejs）几乎可以不使用，但在前端，又几乎不可以不用。

本文会带读者探究关于打包的一切，前辈们是从什么时候开始打包，又从什么时候开始分包？再发展到现在的在开发环境逐渐不再打包，这个过程我们到底经历了哪些故事？我们又可以依靠哪些工具来实现我们不同时期的目标？这一切离不开前端工程的模块化的演进史～

为什么要打包

生活在 script 标签中

<script src="https://code.jquery.com/jquery-3.3.1.slim.min.js" integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.6/umd/popper.min.js" integrity="sha384-wHAiFfRlMFy6i5SRaxvfOCifBUQy1xHdJ/yoi7FRNXMRBu5WHdZYu1hA6ZOblgut" crossorigin="anonymous"></script>
<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.2.1/js/bootstrap.min.js" integrity="sha384-B0UglyR+jN6CkvvICOB2joaf5I4l3gm9GU6Hc1og6Ls7i6U/mkkaduKaBhlAXv9k" crossorigin="anonymous"></script>

在最早的不基于任何前端现代库（React / Vue 等）的原生页面中，如果我们想快捷的搭建一套 b 端页面，bootstrap 是一个很好的选择，你只需要在 script 标签中引入对应库的 cdn 链接即可，然而由于 bootstrap 依赖于 jquery，我们必须把引入 jquery 的标签写在 bootstrap 的前面，不然就会导致报错。

模块化

• Commonjs：简称 cjs，是 nodejs 中默认采用的模块化规范 ，不能直接在浏览器中运行。模块为同步的运行时加载，同时导出变量为值拷贝。

const axios = require("axios");

• AMD：模块异步加载，使用 requirejs 库后可在浏览器端和服务端运行，同时导出变量也为值拷贝。

var requirejs = require('requirejs');
requirejs.config({
    paths: {
        lib1: 'module/index1',
        lib2: 'module/index2'
    }
})
require(["lib1","lib2"], function(l1,l2) {
  l1.doSomething();
  l2.doSomething();
})

• CMD：CMD 的基本逻辑跟 AMD 是一致的，需要使用sea.js库且 CMD 仅支持浏览器端使用。

<script src="https://cdn.bootcdn.net/ajax/libs/seajs/3.0.3/sea.js"></script>
<script>
  seajs.config({
    base: './module/',
    alias: {
      libAMD: 'index.js',
    }
  })
  seajs.use('./main.js')
</script>

// main.js
define(function(require) {
  let libAMD = require("libAMD")
  libAMD.doSomething()
})

• ESM：ECMAscript 的模块化规范，该规范在浏览器端和服务端都得到了支持，在非 default 导出的情况下，导出变量为值的引用，否之亦为值的拷贝。
• 编译时加载
• 支持 tree-shaking

推荐阅读：ES modules: A cartoon deep-dive[1]

import { value, getValue, Obj, name } from "./module/index.js"

环境兼容

打包时的额外工作

• ES6 -> ES5

• TS -> JS

• less / scss -> css

• ......

Webpack VS Rollup

• 业务平台：
• 如果是需要兼容老版本浏览器的场景，更加适合用 Webpack 进行打包，插件生态丰富，提供各种兼容性保障。

• 工具 SDK：
• 更加适合用 Rollup 进行打包，打包内容结构纯净，无多余代码。
• 并且 ESM 对打包工具来说更容易正确地进行 tree-shaking。

为什么要分包

性能优化的考虑

• 手动分包：将体积很小、改动很频繁的业务模块和体积很大、很少改动的第三方库分开打包，这样修改业务模块的代码不会导致第三方库的缓存失效。

• 自动分包：配置好分包策略后 webpack 每次都会自动完成分包的流程，webpack4 中支持了零配置的特性，同时对块打包也做了优化，CommonsChunkPlugin 已经被移除了，现在使用 optimization.splitChunks 作为 CommonsChunkPlugin 的代替。

为什么不打包

以下内容基于 Vite 3

专注于开发体验

核心原理

<script type="module" src="/src/main.tsx">

// main.js
import React from 'react'
import ReactDOM from 'react-dom/client'
import App from './App'
import './index.css'

ReactDOM.createRoot(document.getElementById('root') as HTMLElement).render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
)

tips ：jsx-dev-runtime[3]：React 17 为编译器提供的 jsx to js 库，使用它你甚至不需要手动声明import React from 'react'

bundleless 是完全不进行打包吗？

为什么不在生产环境使用？

尽管原生 ESM 现在得到了广泛支持，但由于嵌套导入会导致额外的网络往返，在生产环境中发布未打包的 ESM 仍然效率低下（即使使用 http2）。为了在生产环境中获得最佳的加载性能，最好还是将代码进行 tree-shaking、懒加载和 chunk 分割（以获得更好的缓存）—— vite 官网

• 用户的浏览器版本可能不支持 ESM / ECMAScript 新版本，使用 bundleless 导致缺失了一些 polyfill 的能力。

总结

• http1.x 中浏览器的并行连接限制；

• 浏览器原生不支持模块化（如 Commonjs 包不能直接在浏览器运行）；

• 项目依赖关系需要管理。

• 分包后浏览器可以缓存极少发生变化的第三方大依赖包，用户刷新页面时只请求频繁变动的业务代码包。

• http2.0 支持多路复用；

• 各大浏览器对 ESM 的支持越来越完善，模块代码可以直接在浏览器中运行，也间接解决了依赖管理的问题。

参考资料