本节通过对比不同的构建工具，分析构建工具的背后设计思想。

摘录&心得

• webpack编译速度较慢，即便启动增量构建，也无法解决初始化构建时长问题
• Parcel内置了多核并行构建
• Parcel内置了文件系统缓存，webpack v5也跟进了该特性

构建工具设计考量指标如下：

1 Code Splitting

• 代码分割
• 能够导出公共模块，避免重复打包
• 页面加载运行时，实现最合理的按需加载策略
• 直接决定了前端资源的静态产出

• 是一个很大的话题

  • 能否支持不同的上下文环境
  • 如何实现 Dynamic Import
  • 代码模块间是否支持 Living Binding
  • ……

    2 Hashing

• 对打包资源进行版本映射

• 打包后的静态文件后会跟着一段哈希字符串。
• 技术重点：最大化利用缓存机制
• 构建工具进行打包的前提是：分析各个模块的依赖关系，支持开发者自定义哈希策略

• Webpack的hash/chunkhash/contenthash策略

  • hash
    • 反应了项目的构建版本
      • 同一次构建过程中生成的 hash 都是一样的
      • 某个模块发生更改，触发项目的重新构建，那么文件的 hash 值将会相应地改变
    • 存在问题：如果某个模块没有变更，重构建后也会产生新hash值，导致缓存命中率低。
  • chunkhash
    • 根据入口文件（Entry）进行依赖解析。
    • 如果改动了业务项目入口文件，就不会引起公共库的 hash 值改变。
  • contenthash
    • 根据文件具体内容，生成 hash 值

      3 Importing Modules

• 要兼容不同类型的 modules importing 方案： ESM、CommonJS

• 也要支持对从 node_modules 引入公共包的支持。

  4 Non-JavaScript Resources

• 对其他非 JavaScript 类型资源导入的支持能力。

  5 Output Module Formats

• 与Importing Modules相对应

• 也要支持不同的导出

  6 Transformations

• 转义

• 在设计构建工具时，对于类似 JSX 的编译、.vue 文件的编译，不会内置到构建工具当中，而是利用 Babel 等社区能力，“无缝融合”到构建流程里。