polyfill & helpers 方案

[imsobear]

Polyfill

类似 Object.values, String.prototype.matchAll，需要前置注入代码一次性修改原型链，不需要替换代码

Package 的做法

• transform: 不关心
• bundle: 打包进去应该是合理的，目前 icepkg 是符合预期的

App 的做法

• 分析 npm 依赖使用到的 polyfill （还没验证）
• 多个地方的 polyfill 合并（还没验证）
• 默认内置的 polyfill（框架本身依赖的、对于体积有优化的），参考 https://nextjs.org/docs/basic-features/supported-browsers-features#polyfills

Helpers

类似 Object Spread({...obj})、Class 关键字、Async/Await 关键字这种，需要将对应代码编译然后替换为对应的实现

Package transform 时的做法

• 正确做法：只引入依赖，方便项目级优化
• build-plugin-component：生成对应 import 语句，比如 import _extends from "@babel/runtime/helpers/extends";
• icepkg：
  • 目前时生成对应的代码实现（swc），不合理，要达成上面的效果需要配置下参数：https://swc.rs/docs/configuration/compilation#jscexternalhelpers ，开启后的效果：import * as swcHelpers from "@swc/helpers";

Package bundle 时的做法

• 正确做法：打包进去，保证可独立运行
• icepkg:
  • @swc/helpers 谁来依赖需要明确一下、另外是否跟其他包一样能被 external

App bunlde 时的做法

• 正确做法：
  • 将不同 npm 包里的 @babel/runtime/helpers 和 @swc/helpers 合并，防止重复引入，也可能会有其他的 helpers 未来需要考虑？
  • 多个地方共用的 helpers 应该只打包一份（项目里不同路由、不同 npm 包等）
  • npm 包里如果将 helpers 编译成了代码实现（不合理），应用级应该就没法优化了，只能冗余
• ICE 3.0：
  • 目前简单测了下不同路由使用同样的 ...obj 语法，会在两个 chunk 里都打包一份 helper 实现
  • NPM 包的情况需要验证
  • @babel/runtime/helpers 和 @swc/helpers 合并，目前肯定没支持

其他

Package transform vs bundle

package bundle 模式的产物在应用里直接使用会导致构建优化不彻底的问题：

1. 上文中提到的 helpers 和 polyfills 都可能会有冗余打包
2. 以前提到的单文件可能引入 tree-shaking 失效问题（需要验证）

[imsobear]

同一项目的不同文件生成了同样的 helpers @ClarkXia 这个应该不合理吧？

[maoxiaoke]

Helpers 的现状

• 不同路由使用了一份 ...obj 语法，两个页面 chunk 都会打包一份实现
• NPM Package 的 ...obj 默认不会导入多份 helper 实现，若不存在代码共享，则当前页面chunk 打包一份；否则，将共享 helper 打包至 vender chunk 中。

若开启 externalHelpers 则，则整体只打包一份产物。

@swc/helper 的版本号不一致的场景

组件和应用使用的 @swc/helper 的版本号不一致，则会重复引入

解法

在应用中锁定 resolve 的 @swc/helper 的版本。

Polyfill 的现状

和 Helpers 的结果一致

解法

在应用中锁定 resolve 的 core-js 的版本。

@babel/runtime 和 @swc/helpers 合并

[ClarkXia]

@maoxiaoke 对于应用而言 如果有低版本浏览器的兼容需求，目前是不是直接通过 swc 的 targets 能力就足够了