我们和 Webpack 团队确立了合作关系,Rspack 作为 Webpack 通过 Rust 进行性能优化的一个尝试,未来我们会和 Webpack 团队一起探索优化 Webpack 的更多可能性。当 Rspack 达到一定的成熟度时,Webpack 团队将尝试以实验特性方式将 Rspack 集成到 Webpack 中。
会带来一定的性能损失,但是根据我们业务落地的情况,这个损失在可接受范围内,我们不会片面的追求 benchmark 指标,而忽视业务的迁移成本。
Rspack 内部使用 SWC 进行代码的降级编译(可以通过 presetEnv),因此无需通过 babel-loader 来进行代码的降级编译。
不是,Rspack 目标也不是完全兼容 100% 的 Webpack API,根据二八定律的原则,我们会优先实现在社区和业务中高频使用的那些 API。
计划支持,我们和 NAPI-RS 团队一起在探索 wasm 方案,目前还在探索阶段,后续会有更多的进展。
即使是 Webpack + SWC-loader 解决了 babel-loader 的性能问题,但是 Webpack 本身仍然存在较多的性能瓶颈,如 make,seal 等阶段都是单线程的,但是 Rspack 突破了这些限制,因此 Rspack 比 Webpack + SWC-loader 有更好的性能表现,尤其是在多核场景。
不需要,目前可以像开发 Webpack 插件和 loader 一样使用 js 开发插件和 loader,同时我们也在探索如何支持业务使用 Rust 开发自定义的插件和 loader。
目前暂无规划,视社区的需求和 React Server Component 的本身发展而决定是否要在 Rspack 里进行支持。
可以,目前已经在多个内部项目中落地了生产环境,我们目标是运行时完全对齐 Webpack(意味着你很难从产物里判断是 Webpack 还是 Rspack 产物),但是目前离完整对齐还有一点差异,我们将在将来完成 Runtime 的完整对齐。