做前端构建已经三年了，从Grunt到Gulp，从webpack到Rollup，再到现在的Vite和ESBuild，经历了前端构建工具的几代变迁。这三年，踩了很多坑，也积累了很多经验。今天，把这些年的感悟和道理分享出来，希望能帮助正在做前端构建的朋友，少走弯路。

先说说我和前端构建的故事。三年前，我刚加入一个前端团队，负责项目的构建配置。那时候，项目用的是webpack 3，配置文件写了好几百行，每次构建都要好几分钟，改一行代码要等十几秒才能看到效果，开发体验很差。

于是，我开始研究前端构建，从webpack的配置优化，到尝试新的构建工具，一路摸索。这三年，我经历了webpack 3到webpack 5的升级，用过Rollup做组件库构建，研究过Parcel的零配置，尝试过ESBuild的极速构建，也体验了Vite的开发体验。

在这个过程中，我踩了很多坑，也明白了很多道理。今天，就把这些感悟分享出来。

一、构建工具没有银弹，适合的才是最好的

这是我最大的感悟。很多人总在问，最好的构建工具是什么？是webpack？是Vite？还是ESBuild？其实，没有最好的构建工具，只有最适合你项目的构建工具。

不同的构建工具，有不同的特点和适用场景：

  • webpack：功能最强大，生态最完善，适合复杂的中大型应用，但配置复杂，构建速度相对较慢。
  • Rollup：专注于ES模块打包，输出的代码更干净，体积更小，适合构建组件库和工具库，但对代码分割、HMR等支持不如webpack。
  • Vite：开发体验极好，启动快，热更新快，基于ESBuild和Rollup，适合现代前端项目，但对一些老旧项目的兼容性可能不够好。
  • ESBuild：构建速度极快，比webpack快几十倍，但功能相对简单，生态不够完善，适合简单的项目或者作为其他工具的底层。
  • Parcel：零配置，开箱即用，适合快速原型和简单项目，但定制化能力不如webpack。

所以，选择构建工具的时候，要根据项目的特点和需求来选，不要盲目跟风。如果是复杂的中大型应用，需要丰富的功能和生态，webpack可能更合适；如果是组件库，Rollup可能更好；如果是新项目，追求开发体验，Vite可能是首选；如果是简单的小项目，Parcel或者ESBuild就够了。

我自己的经验是，不要在一个项目中混用太多构建工具，也不要频繁更换构建工具。选定一个适合的工具，深入研究，把它用好，比频繁换工具更有价值。

二、开发体验和构建性能同样重要

以前，我做构建优化的时候，只关注构建产物的体积和性能，比如代码分割、tree shaking、压缩等，忽略了开发体验。后来我才发现，开发体验和构建性能同样重要，甚至更重要。

开发体验不好，比如启动慢、热更新慢、报错不清晰，会严重影响开发效率。开发者每天要花很多时间等待构建，这种等待是隐形的浪费。而且，糟糕的开发体验会影响开发者的心情和积极性。

所以，做构建优化的时候，要同时关注开发体验和构建性能：

  • 开发阶段：关注启动速度、热更新速度、错误提示的清晰度、source map的质量等。
  • 生产阶段：关注构建产物的体积、加载速度、运行时性能等。

Vite之所以受欢迎，很大程度上就是因为它的开发体验太好了，启动几乎是秒开，热更新也是毫秒级的，开发者不用再等待。这种体验上的提升，比构建产物小几KB更有价值。

我自己的项目，后来也做了开发体验的优化，比如用更快的source map、优化热更新、减少开发阶段的不必要的处理等，开发效率提升了很多。

三、配置要简洁，不要过度工程化

这是我踩过的一个大坑。一开始做构建配置的时候，我总觉得配置越复杂越专业，加了很多插件，做了很多处理，配置文件写了好几百行。结果就是，构建速度很慢，出了问题很难排查，新人接手也很困难。

后来我才明白，配置要简洁，不要过度工程化。每加一个插件，每做一个处理，都要问自己：这个真的有必要吗？带来的收益是什么？代价是什么？

很多时候，一些看似高级的配置，其实带来的收益很小，反而增加了复杂度和维护成本。比如，一些不必要的代码分割、一些花哨的插件、一些过度的优化，可能反而会让构建变慢，让产物变大。

我的建议是：

  • 从简单的配置开始，只加必要的插件和处理。
  • 每加一个配置，都要做基准测试，看看到底有没有提升。
  • 定期清理配置，移除不再需要的插件和处理。
  • 写好注释，说明每个配置的作用，方便后期维护。

简洁的配置，不仅构建速度快，而且出了问题容易排查，新人也容易上手。记住，简单就是美。

四、依赖管理是构建优化的关键

很多人做构建优化，只关注构建工具的配置，忽略了依赖管理。其实，依赖管理才是构建优化的关键。项目的依赖越多、越重，构建就越慢，产物就越大。

我见过很多项目，package.json里有上百个依赖，很多依赖其实根本没用到，或者有功能重复的依赖。这些无用的依赖，不仅增加了安装时间，也增加了构建时间和产物体积。

所以，做构建优化，首先要做依赖管理：

  • 清理无用依赖：定期检查项目的依赖，移除没有用到的依赖。可以用depcheck这样的工具来检测无用依赖。
  • 选择轻量替代：对于一些很重的依赖，看看有没有更轻量的替代品。比如，用dayjs代替moment.js，体积小很多。
  • 按需引入：对于一些大的库，比如lodash、antd等，要按需引入，不要全量引入。可以用babel-plugin-import这样的插件来实现按需引入。
  • 锁定依赖版本：用package-lock.json或者yarn.lock锁定依赖版本，避免因为依赖版本不一致导致的构建问题。
  • 分离依赖：把不常变化的依赖（比如react、vue等框架）和业务代码分开打包，利用浏览器缓存，提升加载速度。

我自己的项目，做了依赖清理之后，构建速度提升了30%，产物体积减少了20%，效果非常明显。所以，依赖管理真的很重要。

五、缓存是提升构建速度的利器

构建速度慢，很多时候是因为重复做了同样的工作。比如，每次构建都要重新编译所有的文件，重新压缩所有的图片，重新做所有的处理。如果能把这些工作的结果缓存起来，下次构建的时候直接用缓存，就能大幅提升构建速度。

现在的构建工具，基本上都支持缓存：

  • webpack：有持久化缓存（cache: { type: 'filesystem' }），可以把构建结果缓存到磁盘，下次构建的时候直接用。
  • Vite：基于ESBuild的预构建缓存，以及模块级别的缓存。
  • ESBuild：有增量构建和缓存机制。
  • 各种loader和plugin：很多loader和plugin也支持缓存，比如babel-loader的cacheDirectory，css-loader的缓存等。

除了构建工具本身的缓存，还可以用一些外部的缓存方案：

  • CI/CD缓存：在CI/CD中，缓存node_modules和构建缓存，避免每次都重新安装和构建。
  • 远程缓存：对于团队协作，可以用远程缓存，比如Nx的远程缓存，一个人构建过的模块，其他人可以直接用缓存，不用重新构建。

我自己的项目，开启了webpack的持久化缓存之后，第二次构建的速度提升了5倍以上，效果非常明显。在CI/CD中缓存了node_modules之后，安装时间从几分钟降到了几十秒。

所以，缓存是提升构建速度的利器，一定要用好。

六、错误处理和可观测性不能忽视

构建出了问题，能不能快速定位和解决，也是衡量构建系统好坏的重要标准。很多构建配置，正常的时候没问题，但一出问题，就一头雾水，不知道哪里错了，怎么解决。

所以，构建系统的错误处理和可观测性，不能忽视：

  • 清晰的错误信息：构建出错的时候，要给出清晰、明确的错误信息，告诉用户哪里错了，为什么错了，怎么解决。不要只给一个模糊的错误，让人摸不着头脑。
  • source map：生产环境的代码是压缩混淆过的，出了问题很难定位。一定要生成source map，这样出了问题，可以通过source map定位到原始代码。
  • 构建日志：构建过程中，要输出清晰的日志，告诉用户每一步在做什么，花了多少时间。这样，构建慢的时候，可以知道慢在哪里，针对性优化。
  • 构建分析：用构建分析工具，比如webpack-bundle-analyzer，分析构建产物的组成，看看哪些模块占的体积大，哪些可以优化。
  • 告警和监控：在CI/CD中，对构建失败、构建时间过长、产物体积过大等情况，设置告警，及时发现问题。

我自己就吃过这方面的亏。有一次，生产环境出了一个bug，但因为没有source map，定位了半天才找到问题所在。还有一次，构建突然变慢了，但因为没有详细的日志，不知道慢在哪里，花了很多时间才排查出来是某个插件的问题。

从那以后，我就很重视构建的错误处理和可观测性，配置了清晰的错误信息、source map、构建日志和分析工具，出了问题能很快定位，构建慢了能很快找到原因。

七、持续优化，但不要过早优化

构建优化是一个持续的过程，不是一次性的工作。项目在不断迭代，依赖在不断更新，需求在不断变化，构建配置也需要不断调整和优化。

但是，也不要过早优化。在项目初期，不要花太多时间在构建优化上，先把功能做出来，先跑起来。等项目有了一定规模，构建速度或者产物体积成了问题的时候，再针对性地优化。

过早优化，不仅浪费时间，而且可能因为项目变化，优化的东西后来没用了，白忙活一场。而且，过早优化可能会让配置变得复杂，影响开发效率。

我的建议是：

  • 项目初期：用默认配置或者简单配置，快速开发，不要过度优化。
  • 项目中期：当构建速度或者产物体积影响开发效率的时候，做针对性的优化。
  • 项目后期：持续监控和优化，保持构建系统的健康。

优化的时候，要有数据支撑，不要凭感觉。先做基准测试，找到瓶颈，然后针对性优化，优化之后再做测试，看看有没有效果。不要盲目地加插件、改配置，那样可能越优化越慢。

八、写在最后

做了三年前端构建，我最大的感悟是：构建工具只是工具，真正重要的是理解构建的原理和思想，根据项目的实际情况，选择合适的工具和配置，解决实际的问题。

不要盲目追求新技术，不要跟风换工具，不要过度工程化。把基础的东西做好，比如依赖管理、缓存、错误处理，比追求花哨的新工具更有价值。

构建优化是一个持续的过程，需要耐心和细心。但只要方向对了，方法对了，就一定能做出一个高效、稳定、易维护的构建系统。

希望这些感悟，能对正在做前端构建的朋友有所帮助。如果有什么问题或者不同的看法，欢迎在评论区交流。