工程&研发 - 1 - 杨健 - Rspack应对大型项目挑战.pdf

《工程&研发 - 1 - 杨健 - Rspack应对大型项目挑战.pdf》由会员分享，可在线阅读，更多相关《工程&研发 - 1 - 杨健 - Rspack应对大型项目挑战.pdf（57页珍藏版）》请在三个皮匠报告上搜索。

1、字节跳动 Web Infra 杨健Rspack：应对型项挑战录1.质疑 Webpack 2.理解 Webpack 3.成为 Webpack 4.超越 Webpack质疑 Webpack?业务背景公司内有相当多的型应(10000+模块)冷启动时间 2-5 分钟，甚更久 构建时间 15-30 分钟，甚更久 HMR 10s+甚更久型项重要吗期项都乎不可避免的成为项 型项往往是公司内较重点的项（否则也活不了这么久）Discord、Slack、Lark、Kibana.型项的性能优化是必须要做的事情优化探索swc-loader esbuild-loader cache-loader thread-load

2、er persistent-cache hard-source-webpack-plugin lazy compilation DllPlugin MFSU治标不治本，性能没提升多少，配置复杂翻倍质疑webpack看来 Webpack 是真的不了 配置程师也救不了理解 Webpack换个 bundler 吧换个 bundlerParcel:架构很好，但奈内部实践太少 Turbopack:架构很好，但是还没诞(Rspack 和 Turbopack 概同时诞)Rollup:库场景良好，应场景性能和功能都缺失的较为严重 esbuild:?Vite:?换个 bundler 吧dev&prod buil

3、d 快如闪电esbuild愁的HMRHook 不持增量构建，rebuild 性能较差 esbuild原不持 HMR，需要通过插件实现，性能下降严重产物性能不佳只持基于 dynamic import 和 multi entry 的拆包 法控制包的体积和并加载数 Es5 持会引起很的性能劣化，且和 splitting 配合不友好 很容易拆分出常多的chunk，离线化场景性能很差 定义的后处理会导致 chunk hash 问题产物性能不佳esbuild的经验验证了基于原语架构的 bundler 的性能天花板常(100 x faster)resolve 和 load hook基于 golang reg

4、ex 的设计巧妙避免了跨语通信开销 验证了没有套基于增量架构的 HMR 是不可的(bundler 再快也没)验证了增量构建中跨语通信是瓶颈问题换个bundler 吧Vite中型项很，开发体验很好 Build 性能虽然般，但是对中型项够Vite瀑布流问题导致 reload|load的性能瓶颈 HMR 并不总是能作 Fast-Refresh 的 bailout 情况常多，型项常容易触发bailout Legacy 代码量循环引，改造兼容成本很Build 性能vite 产环境使 rollup 编译，且不持 cache，导致性能不佳Build 性能真的重要吗？不影响我写代码10 min golden

5、timeCI越，迭代效率越低Build Time MattersCI 可以做更多的事情，预览、包分析、E2E 等 减快速试错的成本(想想改个配置编译 30min）CI Build 成本(如 aws 的 codebuild,省钱才是硬道理)减 HotFix 的时间(热修变冷修)Build Time Matters产物性能拆包能 esbuild 好（持 manualChunks 和 minChunkSize)拆包能仍然是导致其难以应到重要C端应的最阻 重要的C端应通常需要拆包的调优来获得最佳的性能1s=10亿已知问题Vite 的选择vite的经验出的开箱即体验常重要（why we build rs

6、build）兼容态分重要，避免所有轮都要造遍 质量的 loader 和 plugin 包含了数的细节，团队根本法维护 社区关重要（项的第天就决定要按照社区开源的式运营）bundleless 前不适合公司的型业务场景 拆包能关重要，关乎到能不能应到重要C端应Webpack的强项Webpack的弱项Our needs极致的拆包能冷启动性能产环境构建性能HMR性能丰富的态稳定的产物质量迁移成本Legacy code 兼容可控的研成本成为 Webpack为什么选Rust态丰富(swc)语程化做得好 良好的 binding 持(NAPI-RS)最主要的原因（初创团队是 Rust 党）Zig 和 Gola