让日期组件库与宿主应用共享同一份代码temporal-polyfill 面向组件作者的 peer dependency 方案【免费下载链接】temporal-polyfillA lightweight polyfill for Temporal, successor to the JavaScript Date object项目地址: https://gitcode.com/gh_mirrors/tempo/temporal日期选择器、日历网格、排期表……几乎所有前端组件库都要和日期打交道。过去组件作者面临一个两难要么自己捆绑一份 dayjs 或 date-fns让每个安装了组件的应用都白白多背一份日期库要么提供 date-io 之类的适配层把选库的负担甩给用户。而temporal-polyfill带来了一种全新的思路——通过peer dependency 方案让日期组件库与宿主应用共享同一份代码谁都不重复打包。temporal-polyfill 是 JavaScriptDate对象的继任者 Temporal 的轻量级 polyfill体积不到 20 kBgzip 后约 19.5 kB且高度符合规范。它对组件作者最大的价值是内置了一套专为共享而生的 tree-shakeable 函数 API。本文就带你完整看懂这套面向组件作者的 peer dependency 方案。组件库的日期库困境重复打包为何难以避免先看清痛点。假设你的应用同时用了三个组件库——日期选择器、日历、排期表——而它们各自捆绑了自己的日期库方案组件库做法宿主应用的代价捆绑 dayjs/date-fns每个库内置一份同一日期逻辑被打包 N 次手写 Date 工具自己造轮子代码质量参差、容易出 bugdate-io 适配层让用户选库配置复杂用户负担重无论走哪条路每一份日期逻辑都在重复进入最终 bundle。temporal-polyfill 想终结这种局面让 Temporal 成为所有第三方组件终于能达成共识的共享标准。什么是 temporal-polyfill 的 peer dependency 方案核心思路只有一句话组件库不安装、不捆绑 temporal-polyfill只声明它为 peer dependency对等依赖由宿主应用提供唯一的共享安装。这样打包器就能把重复代码去重成一份。第一步在 package.json 中声明 peer dependency在组件库的package.json中把 temporal-polyfill 声明为对等依赖版本范围随意推荐^1.0.1{ peerDependencies: { temporal-polyfill: ^1.0.1 } }这一步之后组件库就不再拥有这份日期代码而是借用宿主应用的那一份。第二步从 fns 入口按需导入函数组件内部不要引入整个 polyfill而是从temporal-polyfill/fns/*只导入你需要的函数// 组件库内部 import * as PlainDateFns from temporal-polyfill/fns/PlainDate const date PlainDateFns.create(2026, 6, 1) const later PlainDateFns.addMonths(date, 2) PlainDateFns.toString(later) // 2026-08-01每个 Temporal 类型都有独立的入口temporal-polyfill/fns/PlainDate、temporal-polyfill/fns/ZonedDateTime、temporal-polyfill/fns/Now等。这些函数操作的是普通记录对象plain record不依赖全局Temporal非常适合嵌入第三方工具。第三步宿主应用提供全局安装是否加载完整 polyfill由宿主应用根据自己的浏览器兼容目标决定——Safari 和较老环境还没有原生Temporal此时宿主通过temporal-polyfill/global入口安装全局 polyfill 即可。最终无论组件还是宿主应用解析到的都是同一份 temporal-polyfill 安装打包器自动去重app | ├─▶ temporal-polyfill/global ····┐ | (可选) | └─▶ DatePicker ├─▶ 一份共享的内部代码 | | └─▶ temporal-polyfill/fns ··┘ (只包含用到的函数)为什么函数 API 特别适合共享tree-shakeable 的威力class 风格的Temporal.*类型很大一个组件库引入它就像引入整个 polyfill。而fns函数 API 的每个操作都是独立的纯函数打包器webpack、Rollup、Vite 等只保留真正被 import 的函数其余全部摇掉tree-shake。这对组件作者意味着三件事按需引入只 import 用到的函数包体极轻共享内幕组件引入的函数内部实现与 polyfill 本体是同一份代码——同一包、同一构建、同一逻辑多个组件各取所需三个组件分别用到不同函数加起来仍然只有一份 Temporal 逻辑进入 bundle宿主应用几乎零额外负担。完整的函数目录、类型导出与示例可以参考 docs/fns/index.md 对应的文档PlainDate、PlainDateTime、ZonedDateTime 等均有独立文档页。共享的前提宿主必须安装 temporal-polyfill要让共享生效宿主应用必须能解析到 temporal-polyfill。有一个值得注意的细节fns函数本身不需要全局Temporal即可运行但toTemporal这类互操作函数会在调用时读取全局Temporal——所以宿主需要在调用它之前安装全局 polyfill推荐temporal-polyfill/global否则会直接抛错。这保证了组件对宿主环境的假设始终透明、可预期。如果你还想看真实代码仓库里的示例项目examples/fns-and-global/完整演示了函数 API 全局 polyfill的组合用法包括自定义历法的处理方式值得组件作者对照阅读。可删除的依赖无锁定随时可以走人这个方案最大的诚意在于它不是一扇单向门。采纳 tree-shakeable API 不是永久承诺。等到原生Temporal覆盖了你所有的目标环境不再需要 polyfill 时仓库自带的迁移工具 temporal-polyfill-codemod 会把你的函数调用机械地改写成地道的Temporal.*语法然后直接删除这个依赖// 迁移前fns 风格 const date PlainDateFns.create(2024, 5, 1) const next PlainDateFns.addDays(date, 3) // 迁移后原生 Temporal const date new Temporal.PlainDate(2024, 5, 1) const next date.add({ days: 3 })因为每个函数与Temporal.*等价方法一一对应迁移是机械性的几乎没有边界情况和调试负担。相关迁移工具的用法和注意事项可查阅codemod/README.md转换契约的完整说明在codemod/ARCHITECTURE.md。总结一份共享、一份去重、一条退路把 temporal-polyfill 作为 peer dependency是日期组件库领域一次漂亮的标准共建✅ 组件库零捆绑、零重复打包宿主只保留一份共享代码✅ 函数 API 天然 tree-shakeable按需引入、体积可控✅ 去留自由原生 Temporal 普及后一行 codemod 命令即可迁移并移除依赖。无论你是组件库作者还是被重复打包困扰的应用开发者这套 peer dependency 方案都值得一试——它让日期库第一次成为像 React、Vue 那样由宿主统一提供的共享基础设施。核心设计说明可以进一步阅读docs/fns/for-component-authors.md这份文档正是官方为组件作者准备的完整指南。【免费下载链接】temporal-polyfillA lightweight polyfill for Temporal, successor to the JavaScript Date object项目地址: https://gitcode.com/gh_mirrors/tempo/temporal创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
