开发工具后端【免费下载链接】firebase-js-sdkFirebase Javascript SDK项目地址https://gitcode.com/gh_mirrors/fi/firebase-js-sdk点击查看免费下载firebase/installations-compat是 Firebase JavaScript SDK 中专门为“旧式”命名空间 APIfirebase.installations()提供服务的兼容层包它把模块化 SDK 的能力重新包装成firebase包时代熟悉的调用方式。本文以该包在仓库中的 CHANGELOG.md 为时间线骨架结合 installationsCompat.ts、index.ts 等源码讲清楚它的定位、实现原理、API 面、底层机制与完整版本演进帮助你理解 Firebase SDK 的 compat 架构以及如何在升级到模块化 API 时正确评估兼容层的行为边界。一、包定位为什么需要一层“兼容层”Firebase Web SDK 在 9.x 时代完成了向模块化modularAPI 的转型每个功能包如firebase/installations只导出纯函数例如getId(installations)、getToken(installations, forceRefresh)并配合firebase/app的 provider 体系按需加载。但大量存量项目仍在使用firebase.installations().getId()这种命名空间写法。installations-compat就是为此而生的桥接包。README.md 明确了两点约束它只是一个 compatibility layer不是独立功能实现不面向直接使用只应通过官方firebase包间接加载。实际消费方也印证了这一点packages/firebase/compat/installations/index.ts 仅一行import firebase/installations-compat而模块化入口 packages/firebase/installations/index.ts 则是export * from firebase/installations。也就是说同一份 Installations 能力通过两个不同包装分别暴露给新旧两套 API 风格。二、核心实现InstallationsCompat 类的四件套 API兼容层的全部业务逻辑都集中在 installationsCompat.ts 中的InstallationsCompat类export class InstallationsCompat implements FirebaseInstallationsCompat, _FirebaseService { constructor( public app: FirebaseApp, readonly _delegate: Installations ) {} getId(): Promisestring { return getId(this._delegate); } getToken(forceRefresh?: boolean): Promisestring { return getToken(this._delegate, forceRefresh); } delete(): Promisevoid { return deleteInstallations(this._delegate); } onIdChange(callback: IdChangeCallbackFn): IdChangeUnsubscribeFn { return onIdChange(this._delegate, callback); } }设计要点委托模式delegation类本身不实现任何 Installations 业务逻辑全部转调模块化包的顶层函数_delegate保存底层模块化实例。这是 SDK 内部“compat 包只做 API 形态翻译”这一统一原则的直接体现。双接口约束implements FirebaseInstallationsCompat来自 packages/installations-types/index.d.ts 的FirebaseInstallations接口确保对外类型与旧 API 完全一致implements _FirebaseService则是 app-compat 对“挂载在 FirebaseApp 上的服务”的通用契约要求服务暴露app属性并实现_delete。方法签名一一对应getId(): Promisestring、getToken(forceRefresh?: boolean): Promisestring、delete(): Promisevoid、onIdChange(callback): () void与命名空间时代的 API 完全对齐因此旧代码可以无痛迁移。类型层面的契约定义在 installations-types/index.d.tsgetId在不存在 Installation 时创建并返回 FIDgetToken返回当前 Installation 的认证令牌forceRefresh可强制刷新delete删除 Installation 及其关联数据onIdChange注册 FID 变化回调并返回取消订阅函数。三、组件注册如何把 compat 服务挂进命名空间InstallationsCompat类本身不会生效必须通过 Firebase 的组件Component体系注册。见 src/index.tsfunction registerInstallations(instance: _FirebaseNamespace): void { instance.INTERNAL.registerComponent( new Component( installations-compat, container { const app container.getProvider(app-compat).getImmediate()!; const installations container .getProvider(installations) .getImmediate()!; return new InstallationsCompat(app, installations); }, ComponentType.PUBLIC ) ); instance.registerVersion(name, version); }这段代码揭示了三条关键链路依赖注入工厂函数通过container.getProvider(app-compat)拿到命名空间 App再通过getProvider(installations)拿到模块化 Installations 实例——兼容层自己不创建任何底层状态完全复用模块化服务的单例。命名空间扩展文件末尾的declare module firebase/app-compat为FirebaseNamespace增加installations(app?: FirebaseApp)、为FirebaseApp增加installations()方法这正是firebase.installations()语法得以成立的 TypeScript 类型来源。版本登记registerVersion(name, version)把firebase/installations-compat的包名与版本写入 SDK 运行时版本表用于日志与诊断。firebase/installations模块化包自身也做同样的事见 functions/config.ts注册installationsPUBLIC与installations-internalPRIVATE两个组件后者供 Messaging 等其他 SDK 通过_FirebaseInstallationsInternal内部接口调用getId/getToken。所以整个链条是firebase.installations()→ compat 组件工厂 → 模块化installations组件实例 → 底层 IndexedDB 网络请求。四、底层原理模块化 API 究竟做了什么兼容层只是翻译层真正的 Installations 语义在 packages/installations/src 中。理解底层有助于判断兼容层调用的代价与边界getIdapi/get-id.ts调用getInstallationEntry读取/创建本地条目返回installationEntry.fid若尚未注册则注册请求在后台进行registrationPromise.catch(console.error)若已注册则顺手刷新令牌——因此getId可能伴随一次网络注册。getTokenapi/get-token.ts先completeInstallationRegistration等待注册完成再经refreshAuthToken返回令牌forceRefresh为 true 时无视过期时间强制刷新。deleteInstallationsapi/delete-installations.ts未注册条目直接本地删除注册中IN_PROGRESS抛DELETE_PENDING_REGISTRATION已注册则先发删除请求再清本地记录离线时抛APP_OFFLINE。onIdChangeapi/on-id-change.ts通过addCallback/removeCallback维护按appConfig分组的回调表返回取消函数。状态机与常量helpers/get-installation-entry.ts、util/constants.ts本地条目在NOT_STARTED → IN_PROGRESS → COMPLETED之间流转注册中条目的超时上限PENDING_TIMEOUT_MS 1000010 秒令牌提前刷新缓冲TOKEN_EXPIRATION_BUFFER 60 * 60 * 10001 小时认证版本INTERNAL_AUTH_VERSION FIS_v2API 端点指向https://firebaseinstallations.googleapis.com/v1。这些细节解释了兼容层 API 的异步行为getId()可能触发网络注册、getToken()可能等待并刷新令牌、delete()在特定状态下会抛错——与模块化 API 行为完全一致。五、版本演进从 0.1.0 到 0.2.24 的关键节点CHANGELOG 记录了该包从诞生到当前的完整历程其中能反映 SDK 工程策略变化的节点值得单独梳理5.1 模块化首发0.1.00.1.0 的 Minor Changes 标题即“Release modularized SDKs”同时把firebase/installations升到 0.5.0、installations-types升到 0.4.0。这是整个 Firebase JS SDK 从命名空间架构切到模块化架构的起点compat 包从此承担“老代码不坏”的兼容使命。5.2 包结构现代化0.1.3 ~ 0.1.100.1.3为所有包增加exports字段统一 Node/浏览器/类型解析入口0.1.4修正 build 脚本以适配exports字段0.1.10为exports字段补充类型声明fixes #6300并修正package.json中错误的路径。对应现在的 package.jsonexports[.]同时提供types、requireCJS、defaultESM三个条件出口main/module/browser/typings字段并存——这是现代打包器与旧工具链兼容的典型配置。5.3 运行时与构建目标收紧0.1.6 ~ 0.2.190.1.6移除idb第三方依赖改用 SDK 自研的 IndexedDB 封装对应firebase/installations内的 helpers/idb-manager.ts减少依赖面0.2.10移除 ES5 bundle最低支持 ES20170.2.19构建目标统一提升到 ES20200.2.11升级 TypeScript 5.5.40.2.0 时升级到 4.7.4同时带动component、util、installations等依赖同步升版。这些变更属于 SDK 全局工程策略在 compat 包上的落地持续收紧浏览器基线、跟进编译器版本并通过 lerna changesets 自动联动所有依赖包。5.4 依赖治理0.2.23 ~ 0.2.240.2.23为 compat 包新增firebase/app作为peerDependencies。当前 package.json 中peerDependencies为firebase/app: 0.x与firebase/app-compat: 0.x确保宿主环境显式提供基础运行时0.2.24批量更新顶层devDependencies当前为rollup 4.62.2、typescript 5.5.4、firebase/app-compat 0.5.19等并同步firebase/component0.7.5、firebase/installations0.6.24、firebase/installations-types0.5.5、firebase/util1.15.3。六、依赖关系与版本同步机制从 CHANGELOG 的 “Updated dependencies” 段可以清晰看到 compat 包的依赖拓扑firebase/installations功能实现、firebase/installations-types类型契约、firebase/componentDI 容器、firebase/util公共工具。这四者在每次发版时几乎同进同退版本号强耦合——这正是 monorepo 中 changesets 自动版本联动的结果底层包任一 Minor/Patch 变更compat 包必然跟着升一个 Patch 并记录对应 commit。对使用者的实际含义安装firebase全量包时firebase/installations-compat是“附带”依赖而非独立选择项只有当代码同时需要命名空间 API 与 Installations 能力时它才会被真正初始化。七、质量保障测试如何验证委托行为installationsCompat.test.ts 用 vitest 对InstallationsCompat逐一验证“方法调用被转发到模块化 API”getId()应调用模块化getId(installations)并返回其 Promise 结果getToken()应调用getToken(installations, undefined)确认forceRefresh默认未传delete()应调用deleteInstallations(installations)onIdChange(cb)应调用onIdChange(installations, cb)并原样返回 unsubscribe 函数。测试通过vi.mock(firebase/installations, { spy: true })与vi.spyOn打桩配合 testing/util.ts 提供的getFakeApp()/getFakeInstallations()假对象在无浏览器环境下验证了兼容层“只翻译、不改语义”的核心承诺。结合 package.json 中的test:all: vitest run、type-check: tsc -p . --noEmit、trusted-type-check: tsec脚本该包具备完整的类型安全与行为回归保障。八、结语兼容层不是黑盒firebase/installations-compat的 CHANGELOG 表面上是流水账式的版本记录实则是 Firebase JS SDK 架构转型期“模块化内核 兼容外壳”策略的缩影内核能力全部来自firebase/installationscompat 层只负责把函数式 API 重新包装成firebase.installations()命名空间形态并通过组件注册、类型扩展与版本登记融入 app-compat 体系。读懂这层包装你就能在迁移模块化 API 时精确评估兼容层的行为成本也能在排查firebase.installations()相关问题时顺着 provider 链路直达 packages/installations/src 的真实实现。赞分享开发工具后端【免费下载链接】firebase-js-sdkFirebase Javascript SDK项目地址https://gitcode.com/gh_mirrors/fi/firebase-js-sdk点击查看免费下载相关推荐从 v8 命名空间到模块化架构Firebase JS SDK 中 app-compat 兼容层的版本演进与实现解析从 v8 命名空间到模块化架构Firebase JS SDK 中 app compat 兼容层的版本演进与实现解析 本文以 packages/app comp开发工具后端firebase-js-sdk 中的 Firebase Installations 公共接口从 Installations 对象到 FID 与认证令牌的完整指南firebase js sdk 中的 Firebase Installations 公共接口从 Installations 对象到 FID 与认证令牌的完整指开发工具后端兼容层包的架构与演进深入解析 firebase-js-sdk 的 firebase/analytics-compat兼容层包的架构与演进深入解析 firebase js sdk 的 firebase/analytics compat firebase/analytics开发工具后端上一篇Unison 语言 Text 与 Bytes 的 UTF-8 转换toUtf8 / fromUtf8 实战与实现解析下一篇HarmonyOS 仓颉示例 12-Pinwheel 深度解析Image 旋转动画与 Slider 联动实现可调速风车创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考