莫方教程网

专业程序员编程教程与实战案例分享

2025年02月19日

探究前端项目打包构建的用户故事_前端项目打包上线流程

作者：千米

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

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

为什么要打包

生活在 script 标签中

在广泛使用 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 的前面，不然就会导致报错。

模块化

如果代码都需要像上面说的那样写在标签里，那我们的开发节奏也太难受了！难道要手动粘贴多份代码到一个 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[1]

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

环境兼容

了解了上面所说的模块化，我们就可以依赖上述某一种规范进行各个模块开发，但是这不能让我们立刻开始愉快的“大写特写”。

因为我们所使用的 ESM 模块系统本身就存在环境兼容问题。尽管现如今主流浏览器的最新版本都支持这一特性，但是在几年前的我们还无法忽略用户存在使用老版本浏览器的 case， 所以我们还需要考虑兼容问题。

同时，模块化的方式划分出来的模块文件过多，而前端应用又运行在浏览器中，每一个文件都需要单独从服务器请求回来。零散的模块文件必然会导致浏览器的频繁发送网络请求，由于上文所述的 http1.x 的能力局限性，进而会影响应用使用体验。

随着应用日益复杂，在前端应用开发过程中不仅仅只有 JavaScript 代码需要模块化，HTML 和 CSS 这些资源文件也会面临需要被模块化的问题。 而且从宏观角度来看，这些文件也都应该看作前端应用中的一个模块，只不过这些模块的种类和用途跟 JavaScript 不同。

如果我们的应用能在开发阶段继续享受模块化带来的优势，又不被模块化对生产环境所产生的影响，这样就完美啦！所以打包这一节点出现在了研发环节之中。

打包时的额外工作

在打包时我们的打包工具往往还会通过一些插件（eg. Babel）帮我们做编译和代码混淆等工作：

  • ES6 -> ES5
  • TS -> JS
  • less / scss -> css
  • ......

Webpack VS Rollup

我们的项目有可能是一个业务平台，也有可能是一个工具 SDK，这两种不同的类型的项目选择打包工具时也会有不同的选择。

webpack 打包处理后会把我们自己的代码放在最后面，由于编译结果过于长，就不在文档放编译完整结果了～

上面右图注入的大段代码都是 webpack 自己的兼容代码，目的是自己实现 require、modules.exports、export，让浏览器可以兼容 Commonjs 和 ESM 语法。 可以理解为，webpack 自己实现 polyfill 支持模块语法，rollup 是利用高版本浏览器原生支持 ESM，所以 rollup 无需代码注入。

总结：

  • 业务平台： 如果是需要兼容老版本浏览器的场景，更加适合用 Webpack 进行打包，插件生态丰富，提供各种兼容性保障。
  • 工具 SDK： 更加适合用 Rollup 进行打包，打包内容结构纯净，无多余代码。并且 ESM 对打包工具来说更容易正确地进行 tree-shaking。

为什么要分包

性能优化的考虑

“天下大势分久必合，合久必分”

通过打包工具（eg.webpack）实现前端项目整体模块化的优势固然很明显，但是它同样存在一些弊端，那就是我们项目中的所有代码最终都被打包到了一起，如果我们应用非常复杂，模块非常多的话，我们的打包结果就会特别的大，进而导致我们的系统性能也会变差，首屏加载时间变长。

我们可以使用 webpack-bundle-analyzer 插件来进行打包分析，根据包产物结构图进行分解：

  • 手动分包：将体积很小、改动很频繁的业务模块和体积很大、很少改动的第三方库分开打包，这样修改业务模块的代码不会导致第三方库的缓存失效。
  • 自动分包：配置好分包策略后 webpack 每次都会自动完成分包的流程，webpack4 中支持了零配置的特性，同时对块打包也做了优化，CommonsChunkPlugin 已经被移除了，现在使用 optimization.splitChunks 作为 CommonsChunkPlugin 的代替。

关于分包并不是本文的重点，在此就不展开讲解了，感兴趣的小伙伴可以阅读：《webpack 分包》[2]

为什么不打包

以下内容基于 Vite 3

专注于开发体验

如果使用打包式构建，无论是项目启动还是文件变更，都需要完整的走一遍打包过程。 以 Webpack 为例，我们就会经历依赖分析、代码转译和打包的过程，哪怕我们只是简单的修改了一行文案。

当然分包会在一定程度上缓解这一问题，但我们仍然需要对分包后的业务代码包也执行完整的打包流程。

当我们开始构建越来越大型的应用时，需要处理的 JavaScript 代码量也呈指数级增长。包含数千个模块的大型项目相当普遍。基于 JavaScript 开发的工具就会开始遇到性能瓶颈：通常需要很长时间才能启动开发服务器，即使使用模块热替换（HMR），文件修改后的效果也需要几秒钟才能在浏览器中反映出来。如此循环往复，每次几分钟的起步时间让开发者变得很痛苦。

bundleless 工具旨在利用生态系统中的新进展解决上述问题：浏览器更好的原生支持 ESM，且越来越多 JavaScript 工具使用编译型语言编写。

使用 bundleless 工具，我们不用对业务代码进行依赖分析、打包，ESM 会帮助我们在浏览器中完成依赖的分析。当文件发生变更时，本地开发服务只是提供了文件的映射，只需要重新转译对应的文件，并重新替换即可。

核心原理

我们声明一个 script标签类型为 module 时，如：