webpack bundle 主要分两部分

  • 项目文件，pages目录
  • 依赖模块，node_modules目录

https://gitee.com/hy417393356/saas-ui
https://search.gitee.com/?skin=rec&type=repository&q=alibabacloud-console-components&sort=best_match
https://csr632.gitee.io/a**-components/guides/quick-start

源码编译可选 babel、swc 和 esbuild

  • 源码编译
  • 依赖编译

esbuild 适用于 dev；因为快
swc 适用于 build；不支持 top level await，和 mfsu 会有些冲突
源码编译用 esbuild 相比 babel 在 M1 2020 无缓存情况下会快 3s
css 压缩 cssnano
js 压缩 swc、terser 和 uglifyJs

esbuild

esbuild 不仅用于压缩，还被用到 JS/TS 文件实时编译、import/export 分析、测试等环节
esbuild 压缩 CSS 速度提升 6 倍，而尺寸仅增加约 1%

充分利用缓存和多线程
按需编译
Code Splitting
Tree Shaking
Ast To Code
hmr
配置覆盖率
首屏性能优化
UI 好看，交互流畅

  1. 合理的缓存和预加载策略，这样页面切换更快

babel

Babel语言特性又分两类，编译类和补丁类
Babel 覆盖范围只有项目代码，Bundler 层覆盖整个产物

  • Babel 作为编译器不应该处理 modules 类型的转换，比如 esm 到 cjs 或 systemjs，
  • modules 类型的转换应交给 Bundler，Bundler 通常还要依赖 esm 模块做 tree-shaking，所以 preset-env 里的 modules 是个废配置，始终设为 false 就好
  • plugin-transform-runtime 不要配 corejs 带上补丁，不管是项目还是组件；
    • 因为：这部分应该用 babel-polyfill 来解决，毕竟是兼容IE浏览器，最新的浏览器要这些补丁做啥呢？

MFSU 联邦模块

MFSU，Module Federation based Speed Up solution
Module Federation，联邦模块
基于 Webpack 5 Module Federation 出发而实现的提速方案，Module Federation 也是目前在用的预编译产物格式
MFSU，相对于 esbuild，解决：build构建时兼容性问题

MFSU特点

  • 基于 webpack，相比 esbuild + esm 基本无兼容问题，复用 Webpack 生态
  • 适合 build场景，不适合 dev场景
    • 利用缓存让 CI、流程 build 等同样快
  • 首次编译不会那么快，因为需要预编译依赖，但二次编译和改完代码后的热编译效果会很好
    • 因为二次没有编译 node_modules 依赖


MFSU 所做的最重要的事就是预编译 node_modules 并把他缓存起来，以避免重复编译，让日常开发只编译项目文件
加 ANALYZE=1 后看到的只有项目文件，同时由于整体 Bundle 的减少，改完代码后的热编译也会快地多

  • webpack 预编译，输出 Module Federation 格式
  • Module Federation Loader 加载预编译好的依赖

Vite首次编译

  • 预编译依赖用 esm 格式，基于 esbuild，比 MFSU 快地多
  • 热更新快，
    • 因为项目文件按需编译
  • 启动快但浏览器打开慢是 Bundless 方案（包括 Vite）的通病，原因：请求多。
  • MFSU 的解法是和 Bundle 方案一样通过 code splitting 做 chunks 合并，把大部分依赖合到一个文件里，从此不再有请求数量问题