**“** **打包** **”——一个前端研发无比熟悉的词语**，打包工具从来都不是必要，后端（nodejs）几乎可以不使用，但在前端，又几乎不可以不用。本文会带读者探究关于打包的一切，前辈们是从什么时候开始打包，又从什么时候开始分包？再发展到现在的在开发环境逐渐不再打包，这个过程我们到底经历了哪些故事？我们又可以依靠哪些工具来实现我们不同时期的目标？**这一切离不开前端工程的模块化的演进史～** # 为什么要打包 ## 生活在 script 标签中 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/40f4437ce9364b4e8180c63dfdf77a91~tplv-k3u1fbpfcp-zoom-1.image) *前端发展简史* 在广泛使用 http1.x 的时代，我们并不能很好的利用带宽：**一个** **TCP** **连接同时只能有一个 http 请求和响应**。如果正在发送一个 http 请求，那其他的 http 请求就得排队。为了缓解这个问题，**浏览器会对同一个域名建立多个** **TCP** **连接，来实现 http 的** **并发** **。** 但这也对服务器造成不小的负担，所以浏览器做了限制，所以**同一个域名下** **TCP** **连接数最多会在 6 ~ 8 个左右。** 而在 node.js 未诞生时，Javascript 做为一门脚本语言，只能运行在 HTML 的 ` ``` > 在最早的不基于任何前端现代库（React / Vue等）的原生页面中，如果我们想快捷的搭建一套b端页面，bootstrap是一个很好的选择，你只需要在 script 标签中引入对应库的 cdn 链接即可，然而由于 bootstrap 依赖于 jquery，**我们必须把引入 jquery 的标签写在 bootstrap 的前面，不然就会导致报错。** ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4b6bf08182da4420be622803e72813cc~tplv-k3u1fbpfcp-zoom-1.image) ## 模块化如果代码都需要像上面说的那样写在标签里，那我们的开发节奏也太难受了！难道要手动粘贴多份代码到一个 js 文件？变量重名该怎么处理？先别急，请看下面：随着模块化方案：Commonjs、AMD、UMD、ESM 的出现，我们的代码组合方法变得多种多样，也变得更加灵活。 - 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 **仅支持浏览器端使用。** ``` ``` ``` // main.js define(function(require) { let libAMD = require("libAMD") libAMD.doSomething() }) ``` - ESM：ECMAscript 的模块化规范，该规范在**浏览器端和服务端都得到了支持**，在非 default 导出的情况下，**导出变量为值的引用，否之亦为值的拷贝。** - 编译时加载 - 支持 tree-shaking > 推荐阅读：[ES modules: A cartoon deep-dive](https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/) ``` import { value, getValue, Obj, name } from "./module/index.js" ``` ## 环境兼容了解了上面所说的模块化，我们就可以依赖上述某一种规范进行各个模块开发，但是这不能让我们立刻开始愉快的“大写特写”。因为我们所使用的 ESM 模块系统本身就存在**环境兼容问题**。尽管现如今主流浏览器的最新版本都支持这一特性，但是在**几年前的我们还无法忽略用户存在使用老版本浏览器的 case，** 所以我们还需要考虑兼容问题。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7af864f4bcc04f1ca9b1a0852acf3d69~tplv-k3u1fbpfcp-zoom-1.image) 同时，模块化的方式划分出来的模块文件过多，而前端应用又运行在浏览器中，每一个文件都需要单独从服务器请求回来。零散的模块文件必然会导致浏览器的频繁发送网络请求，由于上文所述的 http1.x 的能力局限性，进而会**影响应用使用体验**。随着应用日益复杂，**在前端应用开发过程中不仅仅只有** **JavaScript** **代码需要模块化，** **HTML** **和** **CSS** **这些资源文件也会面临需要被模块化的问题。** 而且从宏观角度来看，这些文件也都应该看作前端应用中的一个模块，只不过这些模块的种类和用途跟 JavaScript 不同。 **如果我们的应用能在开发阶段继续享受模块化带来的优势，又不被模块化对生产环境所产生的影响，这样就完美啦！所以** **打包** **这一节点出现在了研发环节之中。** ## 打包时的额外工作在打包时我们的打包工具往往还会通过一些插件 (eg. Babel) 帮我们做**编译**和**代码混淆**等工作： - ES6 -> ES5 - TS -> JS - less / scss -> css - ...... ## Webpack VS Rollup 我们的项目有可能是一个业务平台，也有可能是一个工具 SDK，这**两种不同的类型的项目选择** **打包** **工具时也会有不同的选择。** ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/976ce0ae2f21428fb5674eb28c43baf0~tplv-k3u1fbpfcp-zoom-1.image)![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2658915257604575b9a10df7ba259a60~tplv-k3u1fbpfcp-zoom-1.image) webpack 打包处理后会把我们自己的代码放在最后面，由于编译结果过于长，就不在文档放编译完整结果了～上面右图注入的大段代码都是 **webpack** **自己的兼容代码**，**目的是自己实现 require、modules.exports、export，让浏览器可以兼容 Commonjs 和 ESM 语法。** 可以理解为，webpack 自己实现 polyfill 支持模块语法，rollup 是利用高版本浏览器原生支持 ESM，所以 rollup 无需代码注入。总结： - 业务平台： - 如果是需要兼容老版本浏览器的场景，更加适合用 Webpack 进行打包，插件生态丰富，提供各种兼容性保障。 - 工具 SDK： - 更加适合用 Rollup 进行打包，打包内容结构纯净，无多余代码。 - 并且 ESM 对打包工具来说更容易正确地进行 tree-shaking。 # 为什么要分包 ## 性能优化的考虑 “天下大势分久必合，合久必分” 通过打包工具（eg.webpack）实现前端项目整体模块化的优势固然很明显，但是它同样存在一些弊端，那就是我们项目中的所有代码最终都被打包到了一起，如果我们应用非常复杂，模块非常多的话，我们的打包结果就会特别的大，**进而导致我们的系统性能也会变差，首屏加载时间变长**。我们可以使用`webpack-bundle-analyzer` 插件来进行打包分析，根据包产物结构图进行分解： ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9cb3cff26b524a3e85225dde5dd0b72c~tplv-k3u1fbpfcp-zoom-1.image) - 手动分包：将**体积很小、改动很频繁的业务模块**和**体积很大、很少改动的第三方库**分开打包，这样修改业务模块的代码不会导致第三方库的缓存失效。 - 自动分包：配置好分包策略后 webpack 每次都会**自动完成分包**的流程，webpack4 中支持了零配置的特性，同时对块打包也做了优化，CommonsChunkPlugin 已经被移除了，现在使用 optimization.splitChunks 作为 CommonsChunkPlugin 的代替。关于分包并不是本文的重点，在此就不展开讲解了，感兴趣的小伙伴可以阅读：[相关文章](https://juejin.cn/post/7142797454490992653) # 为什么不打包 > 以下内容基于 Vite 3 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ba080f9105e14238a38e81326f3557c3~tplv-k3u1fbpfcp-zoom-1.image) ## 专注于开发体验如果使用打包式构建，**无论是项目启动还是文件变更，都需要完整的走一遍打包过程。** 以 Webpack 为例，我们就会经历**依赖分析、代码转译和打包**的过程，哪怕我们只是简单的修改了一行文案。当然**分包**会在一定程度上缓解这一问题，但我们仍然需要对分包后的业务代码包也执行完整的打包流程。当我们开始构建越来越大型的应用时，需要处理的 JavaScript 代码量也呈指数级增长。包含数千个模块的大型项目相当普遍。基于 JavaScript 开发的工具就会开始遇到性能瓶颈：通常需要很长时间才能启动开发服务器，即使使用模块热替换（HMR），文件修改后的效果也需要几秒钟才能在浏览器中反映出来。如此循环往复，每次几分钟的起步时间让开发者变得很痛苦。 bundleless 工具旨在利用生态系统中的新进展解决上述问题：**浏览器更好的原生支持 ESM，且越来越多** **JavaScript** **工具使用编译型语言编写。** 使用 bundleless 工具，我们不用对业务代码进行依赖分析、打包，**ESM 会帮助我们在浏览器中完成依赖的分析**。当文件发生变更时，本地开发服务只是提供了文件的映射，只需要重新转译对应的文件，并**重新替换**即可。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5a1aace5baa6416391babccf93f5ed3f~tplv-k3u1fbpfcp-zoom-1.image) ## 核心原理我们声明一个 `script`标签类型为 `module` 时，如 ```