后端【免费下载链接】google-api-nodejs-clientGoogles officially supported Node.js client library for accessing Google APIs. Support for authorization and authentication with OAuth 2.0, API Keys and JWT (Service Tokens) is included.项目地址https://gitcode.com/gh_mirrors/go/google-api-nodejs-client点击查看免费下载本文以 google-api-nodejs-client 仓库中 firebaserules 模块的 CHANGELOG 为主线完整梳理该模块自 2021 年发布 v0.1.0 以来的全部版本演进、破坏性变更与依赖升级脉络并结合仓库内生成的源码v1.ts、package.json深入讲解 Firebase Rules API 的规则集、发布与测试能力给出可直接运行的 Node.js 调用示例帮助读者安全地升级依赖并正确使用该客户端。一、模块定位Firebase Rules API 的官方 Node.js 客户端firebaserules是 google-api-nodejs-client 中针对 Firebase Rules APIfirebaserules.googleapis.com的独立子包其核心职责在仓库文档中定义得非常明确Creates and manages rules that determine when a Firebase Rules-enabled service should permit a request创建并管理用于决定 Firebase Rules 启用的服务何时应允许请求的规则详见 模块 README 与 v1.ts 中的 API 注释。在仓库整体架构中它与其他上百个 API 子模块并列存在根目录的 src/index.ts 通过export {firebaserules_v1} from ./apis/firebaserules/v1对外导出而 release-please-config.json 将src/apis/firebaserules登记为一个独立发布单元因此该模块拥有自己独立的 npm 包名googleapis/firebaserules和独立版本号当前为 10.0.1见 package.json。从 模块入口 index.ts 可以看到它的标准使用方式通过google.firebaserules(v1)工厂方法创建客户端实例并由googleapis-common的getAPI完成版本分发目前唯一受支持的版本是v1。二、版本演进全景四大阶段的技术脉络该模块的 CHANGELOG 记录了从 2021-06 的 v0.1.0 到 2026-09 的 v10.0.1 共三十余个版本按技术主题可清晰划分为四个阶段。阶段一0.x 功能积累期2021-06 至 2022-09这一阶段以update the API重新生成 API 绑定为主旋律几乎每个小版本都是对上游 Discovery 文档的同步v0.1.02021-06-18首次发布通过 generator 生成v0.2.02021-06-18引入 workload identity federation 认证支持对应 auth 层的功能增强v0.2.1~v0.3.4多次 API 更新51b10c6、6eac040、4810143等提交同步上游规则服务的变化v0.3.0同时把googleapis-common依赖升级到 v5。阶段二1.x 稳定版与依赖升级期2022-10 至 2025-05v1.0.02022-10-28首个 1.0 里程碑。破坏性变更来自构建侧子模块的最低 Node 版本要求提升到Node 12见 CHANGELOG 对应条目v1.0.1~v1.0.52023-08 至 2023-10持续同步 API5e24b10等并把googleapis-common升级到 v7v1.1.0、v1.2.02024-01API 更新2a44570v1.2.1~v1.2.32024-05 至 2025-02API 更新与 Bug 修复。阶段三2.x/3.x 的 Node 18 基线2025-05 至 2025-08v2.0.02025-05-29与v3.0.02025-06-30破坏性变更均为upgrade to node 18最低 Node 版本从 12 提升到 18提交682fbb8伴随googleapis-common升级到 8.0.2-rc随后v3.0.2正式升级到googleapis-common8.0.0提交c9fdf4bv3.0.1包含两次 firebaserules API 更新7e71dbd、45a4451。阶段四4.x 至 10.x 的快速迭代与 Node 22 基线2025-09 至 2026-092025 年 9 月起模块进入高频发布节奏破坏性变更密集出现v4.0.02025-09-16随库整体 release并将googleapis-common升级到 8.0.0v5.0.02025-10-15generator 重新生成4ba19d0v5.0.12025-12-05API 更新ce90e92v6.0.02026-08-03generator 重新生成c429a9bPR #3955v6.1.02026-09-02generator 重新生成5f7d438PR #3992v7.0.0/v8.0.02026-09-09/09-10破坏性变更聚焦Update apiary to minimum Node version of 22PR #4011同时出现 add back support for node 18 与 upgrade dependencies in generated packages to Node 22 两次方向相反的修复提交反映了 Node 18/22 支持策略的反复调整v9.0.02026-09-10Node 22 基线最终确立v10.0.02026-09-14再次确认Node 22 为最低版本PR #4020v10.0.12026-09-23当前版本API 更新c1ec399。版本演进速览表版本区间时间段最低 Node关键变化v0.1.0 ~ v0.3.62021-06 ~ 2022-09—功能积累、workload identity federation、googleapis-common v5v1.0.0 ~ v1.2.32022-10 ~ 2025-02Node 12首个稳定版、googleapis-common v7v2.0.0 ~ v3.0.22025-05 ~ 2025-08Node 18googleapis-common 8.xv4.0.0 ~ v10.0.12025-09 ~ 2026-09Node 22v10 起generator 高频重生成、Node 22 基线注以上 Node 版本要求均可在 CHANGELOG 的 BREAKING CHANGES 条目中直接溯源当前 package.json 的engines字段亦明确声明node: 22.0.0与 v10 系列保持一致。三、破坏性变更专题升级前必须知道的三件事CHANGELOG 中反复出现的 ⚠ BREAKING CHANGES 可归纳为三类这是升级该模块时的核心风险点。1. Node.js 最低版本要求持续上移这是出现频率最高的破坏性变更Node 12v1.0.0→ Node 18v2.0.0/v3.0.0→ Node 22v9.0.0/v10.0.0。其中 2026 年 9 月的 v7/v8/v9 三次发布还出现了对 Node 18 支持的反复——先是add back support for node 18紧接着upgrade dependencies in generated packages to Node 22最终在 v10.0.0 一锤定音。升级前请务必确认运行环境CI、Docker 镜像、Node 运行时满足22.0.0。2. Generator 重新生成带来的 API 同步run the generator类提交如c429a9b、5f7d438、4ba19d0表示整个模块从上游 Discovery 文档重新生成可能引入新增/移除方法、请求与响应 Schema 字段变化、参数名调整等。从 v4.0.0 开始几乎每个大版本都伴随一次 generator 重生成因此跨大版本升级时必须回归测试所有 firebaserules 调用。3. 底层依赖googleapis-common升级该模块的所有 HTTP 请求最终由googleapis-common的createAPIRequest执行见 v1.ts 中的调用。CHANGELOG 中可见其演进路径v5 → v7 → 8.0.0 → 8.0.2-rc → 8.0.0 →^9.0.0当前 package.json 依赖声明。底层传输层、认证层的任何行为变化都可能影响请求构造与错误处理这也是多次伴随破坏性版本的原因之一。四、结合源码Firebase Rules API 的能力全景该模块虽在 CHANGELOG 中只呈现为版本号 变更类型但对应的 v1.ts 完整揭示了其背后 API 的实体模型与能力边界这正是模块存在的意义。资源层级与核心方法从 v1.ts 的类结构 可看到清晰的三层资源树Firebaserules └── projectsResource$Projects ├── releasesResource$Projects$Releasescreate / delete / get / getExecutable / list / patch └── rulesetsResource$Projects$Rulesetscreate / delete / get / list └── project 级方法test每个方法的 HTTP 细节同样可以在源码中找到例如 projects.test 的实现 明确其请求为POST {rootUrl}/v1/{name}:testrootUrl默认https://firebaserules.googleapis.com/releases.create 与 rulesets.create 的结构与之同构。核心数据模型Schema 族Schema见 v1.ts说明Source/File规则源文件集合File含content、name、fingerprintRulesetSource的不可变快照服务端自动生成ruleset_id含attachmentPoint、metadata.services等字段Release指向某个Ruleset的命名引用字段name如projects/{project_id}/releases/{release_id}与rulesetName均为必填TestRulesetRequest/TestSuite/TestCase规则测试体系可内联source或按Ruleset名测试TestCase定义request、resource、expectation、functionMocksIssue/SourcePosition语法/语义检查问题与源码位置信息行、列、偏移量GetReleaseExecutableResponsegetExecutable返回的可执行规则字节、运行版本与关联 Ruleset 名值得注意的细节TestCase文档v1.ts#L383-L409列出了所有服务统一支持的请求字段auth.uid、auth.token、headers、method、params、path、time这正是编写规则单测时构造request对象的依据而projects.test的注释v1.ts#L525-L526给出了一个真实的firebase.storage规则示例用于校验用户只能上传自己 user id 下匹配.png/.jpg且 MIME 为image/*的图片这类授权逻辑。release 的多版本并行语义releases.create 的 JSDoc 解释了Release命名的最佳实践名称可包含环境名、应用名、版本号且允许多个 Release 同时 live例如projects/foo/releases/prod、projects/foo/releases/prod/v23可分别指向不同 Ruleset从而实现灰度发布与回滚——这正是getExecutable与patchUpdateRelease方法存在的场景。五、实战指南安装、认证与调用示例安装该模块可独立安装为 npm 子包推荐方式见 README$ npm install googleapis/firebaserules也可以安装全量客户端后按需取用$ npm install googleapis创建客户端const {google} require(googleapis); const firebaserules google.firebaserules(v1);认证与鉴权范围根据 v1.ts 中各方法内置的示例建议使用 Application Default Credentials并按需选择 scopeconst auth new google.auth.GoogleAuth({ scopes: [ https://www.googleapis.com/auth/cloud-platform, // 云平台全量权限 https://www.googleapis.com/auth/firebase, // Firebase 读写 https://www.googleapis.com/auth/firebase.readonly, // Firebase 只读 ], }); const authClient await auth.getClient(); google.options({auth: authClient});projects.test支持全部三个 scopereleases.create与rulesets.create示例中仅声明前两个cloud-platform、firebase实际所需权限以 Firebase 项目的 IAM 配置为准。创建 Ruleset 并发布 Release核心工作流Firebase Rules 的部署本质上是一个两步流程先创建 Ruleset再创建指向它的 Release。// 1. 创建 Ruleset不可变规则快照 const ruleset await firebaserules.projects.rulesets.create({ name: projects/my-project, requestBody: { source: { files: [ { name: firebase.storage.rules, content: service firebase.storage { match /b/{bucket}/o { match /users/{userId}/images/{imageName} { allow write: if userId request.auth.uid (imageName.matches(*.png$) || imageName.matches(*.jpg$)) resource.mimeType.matches(^image/); } } }, }, ], }, }, }); console.log(ruleset.data.name); // projects/my-project/rulesets/auto-generated-id // 2. 创建 Release 将 Ruleset 上线 const release await firebaserules.projects.releases.create({ name: projects/my-project, requestBody: { name: projects/my-project/releases/prod, rulesetName: ruleset.data.name, }, }); console.log(release.data);用 projects.test 做规则回归测试test方法可对内联Source做单元测试或对已存在的Ruleset名做回归测试const res await firebaserules.projects.test({ name: projects/my-project, requestBody: { source: {files: [{name: test.rules, content: ...}]}, testSuite: { testCases: [ { expectation: ALLOW, // 或 DENY request: {path: /users/uid123/images/a.png, auth: {uid: uid123}, method: get}, }, ], }, }, }); console.log(res.data.issues); // 语法/语义问题列表 console.log(res.data.testResults); // 与 testCases 一一对应的测试结果源码层面v1.ts#L443-L465确认响应中的issues里ERROR级别问题会阻止测试执行testResults的顺序与testCases严格一致。其他常用操作列出/获取/删除projects.rulesets.list|get|delete、projects.releases.list|get|delete获取可执行规则字节projects.releases.getExecutable({name: projects/my-project/releases/prod})用于服务端校验与分发更新 Release 指向projects.releases.patch配合UpdateReleaseRequest.updateMask部分字段更新。六、版本选择与升级建议结合 CHANGELOG 与 package.json 的当前状态给出以下实操建议运行环境先行若运行环境低于 Node 22不要直接升级到 v9/v10 系列停留在 v4.x~v8.xNode 18或 v1.xNode 12并锁死版本跨大版本必做回归v4 之后几乎每个大版本都伴随 generator 重生成建议在升级后重点回归rulesets.create、releases.create/patch、projects.test三类调用并用 JSON Schema 校验响应体中的新增字段依赖联动升级googleapis-common是传递依赖若项目同时直接使用其他 googleapis 子包注意各模块对googleapis-common版本的要求是否冲突追踪官方节奏仓库的 release-please-config.json 与各模块 CHANGELOG 是发布节奏的权威来源发布频率在 2025-09 之后明显加快v4→v10 仅用一年生产环境建议采用自动化依赖更新并配套集成测试。七、结语firebaserules模块的 CHANGELOG 不仅是一份版本流水账它完整记录了 Firebase Rules API 客户端从 0.x 探索期到 10.x 成熟期的演进轨迹Node 基线从 12 一路提升到 22、googleapis-common从 v5 演进到 v9、规则集/发布/测试三大能力随 generator 重生成持续同步上游。理解这些变更背后的原因Node 版本策略、API 重生成、依赖升级再结合 v1.ts 中的资源模型与 模块 README 的安装指引即可在 Node.js 应用中安全、高效地管理 Firebase Rules 的编写、测试与发布全流程。赞分享后端【免费下载链接】google-api-nodejs-clientGoogles officially supported Node.js client library for accessing Google APIs. Support for authorization and authentication with OAuth 2.0, API Keys and JWT (Service Tokens) is included.项目地址https://gitcode.com/gh_mirrors/go/google-api-nodejs-client点击查看免费下载相关推荐google-api-nodejs-client 中 firebasedynamiclinks 模块的版本演进与 API 实战解读google api nodejs client 中 firebasedynamiclinks 模块的版本演进与 API 实战解读 Firebase Dynam后端深入解析 google-api-nodejs-client 的 manufacturers 模块从 CHANGELOG 看 API 演进、版本策略与实战接入深入解析 google api nodejs client 的 manufacturers 模块从 CHANGELOG 看 API 演进、版本策略与实战接入后端google-api-nodejs-client 的 datafusion 模块版本演进全解析从 v1.0.0 到 v22.0.1 的 CHANGELOG 深度解读google api nodejs client 的 datafusion 模块版本演进全解析从 v1.0.0 到 v22.0.1 的 CHANGELOG 深后端上一篇CoffeeScript 2.0.0-alpha1 发布说明编译器转向 ES2015 输出的首个里程碑下一篇RGF_CJ仓颉版 RGF渲染框架全览核心特性、源码架构与环境约束创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/15 3:47:43 · 阅读 1.2k google-api-nodejs-client firebaserules 模块深度解析：从 v0.1.0 到 v10.0.1 的版本演进与 Firebase Rules API 实战
后端【免费下载链接】google-api-nodejs-clientGoogles officially supported Node.js client library for accessing Google APIs. Support for authorization and authentication with OAuth 2.0, API Keys and JWT (Service Tokens) is included.项目地址https://gitcode.com/gh_mirrors/go/google-api-nodejs-client点击查看免费下载本文以 google-api-nodejs-client 仓库中 firebaserules 模块的 CHANGELOG 为主线完整梳理该模块自 2021 年发布 v0.1.0 以来的全部版本演进、破坏性变更与依赖升级脉络并结合仓库内生成的源码v1.ts、package.json深入讲解 Firebase Rules API 的规则集、发布与测试能力给出可直接运行的 Node.js 调用示例帮助读者安全地升级依赖并正确使用该客户端。一、模块定位Firebase Rules API 的官方 Node.js 客户端firebaserules是 google-api-nodejs-client 中针对 Firebase Rules APIfirebaserules.googleapis.com的独立子包其核心职责在仓库文档中定义得非常明确Creates and manages rules that determine when a Firebase Rules-enabled service should permit a request创建并管理用于决定 Firebase Rules 启用的服务何时应允许请求的规则详见 模块 README 与 v1.ts 中的 API 注释。在仓库整体架构中它与其他上百个 API 子模块并列存在根目录的 src/index.ts 通过export {firebaserules_v1} from ./apis/firebaserules/v1对外导出而 release-please-config.json 将src/apis/firebaserules登记为一个独立发布单元因此该模块拥有自己独立的 npm 包名googleapis/firebaserules和独立版本号当前为 10.0.1见 package.json。从 模块入口 index.ts 可以看到它的标准使用方式通过google.firebaserules(v1)工厂方法创建客户端实例并由googleapis-common的getAPI完成版本分发目前唯一受支持的版本是v1。二、版本演进全景四大阶段的技术脉络该模块的 CHANGELOG 记录了从 2021-06 的 v0.1.0 到 2026-09 的 v10.0.1 共三十余个版本按技术主题可清晰划分为四个阶段。阶段一0.x 功能积累期2021-06 至 2022-09这一阶段以update the API重新生成 API 绑定为主旋律几乎每个小版本都是对上游 Discovery 文档的同步v0.1.02021-06-18首次发布通过 generator 生成v0.2.02021-06-18引入 workload identity federation 认证支持对应 auth 层的功能增强v0.2.1~v0.3.4多次 API 更新51b10c6、6eac040、4810143等提交同步上游规则服务的变化v0.3.0同时把googleapis-common依赖升级到 v5。阶段二1.x 稳定版与依赖升级期2022-10 至 2025-05v1.0.02022-10-28首个 1.0 里程碑。破坏性变更来自构建侧子模块的最低 Node 版本要求提升到Node 12见 CHANGELOG 对应条目v1.0.1~v1.0.52023-08 至 2023-10持续同步 API5e24b10等并把googleapis-common升级到 v7v1.1.0、v1.2.02024-01API 更新2a44570v1.2.1~v1.2.32024-05 至 2025-02API 更新与 Bug 修复。阶段三2.x/3.x 的 Node 18 基线2025-05 至 2025-08v2.0.02025-05-29与v3.0.02025-06-30破坏性变更均为upgrade to node 18最低 Node 版本从 12 提升到 18提交682fbb8伴随googleapis-common升级到 8.0.2-rc随后v3.0.2正式升级到googleapis-common8.0.0提交c9fdf4bv3.0.1包含两次 firebaserules API 更新7e71dbd、45a4451。阶段四4.x 至 10.x 的快速迭代与 Node 22 基线2025-09 至 2026-092025 年 9 月起模块进入高频发布节奏破坏性变更密集出现v4.0.02025-09-16随库整体 release并将googleapis-common升级到 8.0.0v5.0.02025-10-15generator 重新生成4ba19d0v5.0.12025-12-05API 更新ce90e92v6.0.02026-08-03generator 重新生成c429a9bPR #3955v6.1.02026-09-02generator 重新生成5f7d438PR #3992v7.0.0/v8.0.02026-09-09/09-10破坏性变更聚焦Update apiary to minimum Node version of 22PR #4011同时出现 add back support for node 18 与 upgrade dependencies in generated packages to Node 22 两次方向相反的修复提交反映了 Node 18/22 支持策略的反复调整v9.0.02026-09-10Node 22 基线最终确立v10.0.02026-09-14再次确认Node 22 为最低版本PR #4020v10.0.12026-09-23当前版本API 更新c1ec399。版本演进速览表版本区间时间段最低 Node关键变化v0.1.0 ~ v0.3.62021-06 ~ 2022-09—功能积累、workload identity federation、googleapis-common v5v1.0.0 ~ v1.2.32022-10 ~ 2025-02Node 12首个稳定版、googleapis-common v7v2.0.0 ~ v3.0.22025-05 ~ 2025-08Node 18googleapis-common 8.xv4.0.0 ~ v10.0.12025-09 ~ 2026-09Node 22v10 起generator 高频重生成、Node 22 基线注以上 Node 版本要求均可在 CHANGELOG 的 BREAKING CHANGES 条目中直接溯源当前 package.json 的engines字段亦明确声明node: 22.0.0与 v10 系列保持一致。三、破坏性变更专题升级前必须知道的三件事CHANGELOG 中反复出现的 ⚠ BREAKING CHANGES 可归纳为三类这是升级该模块时的核心风险点。1. Node.js 最低版本要求持续上移这是出现频率最高的破坏性变更Node 12v1.0.0→ Node 18v2.0.0/v3.0.0→ Node 22v9.0.0/v10.0.0。其中 2026 年 9 月的 v7/v8/v9 三次发布还出现了对 Node 18 支持的反复——先是add back support for node 18紧接着upgrade dependencies in generated packages to Node 22最终在 v10.0.0 一锤定音。升级前请务必确认运行环境CI、Docker 镜像、Node 运行时满足22.0.0。2. Generator 重新生成带来的 API 同步run the generator类提交如c429a9b、5f7d438、4ba19d0表示整个模块从上游 Discovery 文档重新生成可能引入新增/移除方法、请求与响应 Schema 字段变化、参数名调整等。从 v4.0.0 开始几乎每个大版本都伴随一次 generator 重生成因此跨大版本升级时必须回归测试所有 firebaserules 调用。3. 底层依赖googleapis-common升级该模块的所有 HTTP 请求最终由googleapis-common的createAPIRequest执行见 v1.ts 中的调用。CHANGELOG 中可见其演进路径v5 → v7 → 8.0.0 → 8.0.2-rc → 8.0.0 →^9.0.0当前 package.json 依赖声明。底层传输层、认证层的任何行为变化都可能影响请求构造与错误处理这也是多次伴随破坏性版本的原因之一。四、结合源码Firebase Rules API 的能力全景该模块虽在 CHANGELOG 中只呈现为版本号 变更类型但对应的 v1.ts 完整揭示了其背后 API 的实体模型与能力边界这正是模块存在的意义。资源层级与核心方法从 v1.ts 的类结构 可看到清晰的三层资源树Firebaserules └── projectsResource$Projects ├── releasesResource$Projects$Releasescreate / delete / get / getExecutable / list / patch └── rulesetsResource$Projects$Rulesetscreate / delete / get / list └── project 级方法test每个方法的 HTTP 细节同样可以在源码中找到例如 projects.test 的实现 明确其请求为POST {rootUrl}/v1/{name}:testrootUrl默认https://firebaserules.googleapis.com/releases.create 与 rulesets.create 的结构与之同构。核心数据模型Schema 族Schema见 v1.ts说明Source/File规则源文件集合File含content、name、fingerprintRulesetSource的不可变快照服务端自动生成ruleset_id含attachmentPoint、metadata.services等字段Release指向某个Ruleset的命名引用字段name如projects/{project_id}/releases/{release_id}与rulesetName均为必填TestRulesetRequest/TestSuite/TestCase规则测试体系可内联source或按Ruleset名测试TestCase定义request、resource、expectation、functionMocksIssue/SourcePosition语法/语义检查问题与源码位置信息行、列、偏移量GetReleaseExecutableResponsegetExecutable返回的可执行规则字节、运行版本与关联 Ruleset 名值得注意的细节TestCase文档v1.ts#L383-L409列出了所有服务统一支持的请求字段auth.uid、auth.token、headers、method、params、path、time这正是编写规则单测时构造request对象的依据而projects.test的注释v1.ts#L525-L526给出了一个真实的firebase.storage规则示例用于校验用户只能上传自己 user id 下匹配.png/.jpg且 MIME 为image/*的图片这类授权逻辑。release 的多版本并行语义releases.create 的 JSDoc 解释了Release命名的最佳实践名称可包含环境名、应用名、版本号且允许多个 Release 同时 live例如projects/foo/releases/prod、projects/foo/releases/prod/v23可分别指向不同 Ruleset从而实现灰度发布与回滚——这正是getExecutable与patchUpdateRelease方法存在的场景。五、实战指南安装、认证与调用示例安装该模块可独立安装为 npm 子包推荐方式见 README$ npm install googleapis/firebaserules也可以安装全量客户端后按需取用$ npm install googleapis创建客户端const {google} require(googleapis); const firebaserules google.firebaserules(v1);认证与鉴权范围根据 v1.ts 中各方法内置的示例建议使用 Application Default Credentials并按需选择 scopeconst auth new google.auth.GoogleAuth({ scopes: [ https://www.googleapis.com/auth/cloud-platform, // 云平台全量权限 https://www.googleapis.com/auth/firebase, // Firebase 读写 https://www.googleapis.com/auth/firebase.readonly, // Firebase 只读 ], }); const authClient await auth.getClient(); google.options({auth: authClient});projects.test支持全部三个 scopereleases.create与rulesets.create示例中仅声明前两个cloud-platform、firebase实际所需权限以 Firebase 项目的 IAM 配置为准。创建 Ruleset 并发布 Release核心工作流Firebase Rules 的部署本质上是一个两步流程先创建 Ruleset再创建指向它的 Release。// 1. 创建 Ruleset不可变规则快照 const ruleset await firebaserules.projects.rulesets.create({ name: projects/my-project, requestBody: { source: { files: [ { name: firebase.storage.rules, content: service firebase.storage { match /b/{bucket}/o { match /users/{userId}/images/{imageName} { allow write: if userId request.auth.uid (imageName.matches(*.png$) || imageName.matches(*.jpg$)) resource.mimeType.matches(^image/); } } }, }, ], }, }, }); console.log(ruleset.data.name); // projects/my-project/rulesets/auto-generated-id // 2. 创建 Release 将 Ruleset 上线 const release await firebaserules.projects.releases.create({ name: projects/my-project, requestBody: { name: projects/my-project/releases/prod, rulesetName: ruleset.data.name, }, }); console.log(release.data);用 projects.test 做规则回归测试test方法可对内联Source做单元测试或对已存在的Ruleset名做回归测试const res await firebaserules.projects.test({ name: projects/my-project, requestBody: { source: {files: [{name: test.rules, content: ...}]}, testSuite: { testCases: [ { expectation: ALLOW, // 或 DENY request: {path: /users/uid123/images/a.png, auth: {uid: uid123}, method: get}, }, ], }, }, }); console.log(res.data.issues); // 语法/语义问题列表 console.log(res.data.testResults); // 与 testCases 一一对应的测试结果源码层面v1.ts#L443-L465确认响应中的issues里ERROR级别问题会阻止测试执行testResults的顺序与testCases严格一致。其他常用操作列出/获取/删除projects.rulesets.list|get|delete、projects.releases.list|get|delete获取可执行规则字节projects.releases.getExecutable({name: projects/my-project/releases/prod})用于服务端校验与分发更新 Release 指向projects.releases.patch配合UpdateReleaseRequest.updateMask部分字段更新。六、版本选择与升级建议结合 CHANGELOG 与 package.json 的当前状态给出以下实操建议运行环境先行若运行环境低于 Node 22不要直接升级到 v9/v10 系列停留在 v4.x~v8.xNode 18或 v1.xNode 12并锁死版本跨大版本必做回归v4 之后几乎每个大版本都伴随 generator 重生成建议在升级后重点回归rulesets.create、releases.create/patch、projects.test三类调用并用 JSON Schema 校验响应体中的新增字段依赖联动升级googleapis-common是传递依赖若项目同时直接使用其他 googleapis 子包注意各模块对googleapis-common版本的要求是否冲突追踪官方节奏仓库的 release-please-config.json 与各模块 CHANGELOG 是发布节奏的权威来源发布频率在 2025-09 之后明显加快v4→v10 仅用一年生产环境建议采用自动化依赖更新并配套集成测试。七、结语firebaserules模块的 CHANGELOG 不仅是一份版本流水账它完整记录了 Firebase Rules API 客户端从 0.x 探索期到 10.x 成熟期的演进轨迹Node 基线从 12 一路提升到 22、googleapis-common从 v5 演进到 v9、规则集/发布/测试三大能力随 generator 重生成持续同步上游。理解这些变更背后的原因Node 版本策略、API 重生成、依赖升级再结合 v1.ts 中的资源模型与 模块 README 的安装指引即可在 Node.js 应用中安全、高效地管理 Firebase Rules 的编写、测试与发布全流程。赞分享后端【免费下载链接】google-api-nodejs-clientGoogles officially supported Node.js client library for accessing Google APIs. Support for authorization and authentication with OAuth 2.0, API Keys and JWT (Service Tokens) is included.项目地址https://gitcode.com/gh_mirrors/go/google-api-nodejs-client点击查看免费下载相关推荐google-api-nodejs-client 中 firebasedynamiclinks 模块的版本演进与 API 实战解读google api nodejs client 中 firebasedynamiclinks 模块的版本演进与 API 实战解读 Firebase Dynam后端深入解析 google-api-nodejs-client 的 manufacturers 模块从 CHANGELOG 看 API 演进、版本策略与实战接入深入解析 google api nodejs client 的 manufacturers 模块从 CHANGELOG 看 API 演进、版本策略与实战接入后端google-api-nodejs-client 的 datafusion 模块版本演进全解析从 v1.0.0 到 v22.0.1 的 CHANGELOG 深度解读google api nodejs client 的 datafusion 模块版本演进全解析从 v1.0.0 到 v22.0.1 的 CHANGELOG 深后端上一篇CoffeeScript 2.0.0-alpha1 发布说明编译器转向 ES2015 输出的首个里程碑下一篇RGF_CJ仓颉版 RGF渲染框架全览核心特性、源码架构与环境约束创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考