后端【免费下载链接】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点击查看免费下载ondemandscanning是 google-api-nodejs-client 仓库中用于调用 Google On-Demand Scanning API 的客户端模块其核心能力是对容器镜像进行按需漏洞扫描。本文以该模块的 CHANGELOG.md 为骨架系统梳理从 0.2.0 到 29.3.0 的五年版本演进脉络并结合仓库内 模块源码、package.json 与 生成器 等源码证据解释 Node.js 运行时要求、googleapis-common 依赖与 API 定义的持续变化最后给出基于最新版客户端发起一次漏洞扫描的完整实战路径。读完本文你将能看懂这份自动生成的变更记录背后的工程含义并掌握该模块的正确使用方式。一、认识 ondemandscanning为容器镜像漏洞扫描而生的客户端模块ondemandscanning模块封装的是 Google 的On-Demand Scanning API其定位在模块 README.md 与 v1.ts 中有明确描述A service to scan container images for vulnerabilities.用于扫描容器镜像漏洞的服务。它允许客户端提交一个容器镜像的资源 URI由 Google 侧按需分析镜像中的软件包并返回漏洞CVE、恶意内容、SBOM 等扫描结果。从 index.ts 可以看出该模块同时维护v1与v1beta1两个 API 版本两者均导出Ondemandscanning客户端类export const VERSIONS { v1: ondemandscanning_v1.Ondemandscanning, v1beta1: ondemandscanning_v1beta1.Ondemandscanning, };对应的 discovery 文档也成对存放于仓库 discovery/ondemandscanning-v1.json 与 discovery/ondemandscanning-v1beta1.json。在 monorepo 主包中该模块通过 src/apis/index.ts 统一导出ondemandscanning: ondemandscanningVersions因此既可以从主包googleapis访问也可以独立安装发布到 npm 的googleapis/ondemandscanning包。二、CHANGELOG 是什么release-please 自动生成的版本台账这份 CHANGELOG 并非手写文档而是 Google 仓库使用的release-please工具基于 Conventional Commits 自动生成的发布记录。其结构高度规范每个版本条目包含版本号与日期采用语义化版本SemVer格式如29.3.02026-10-14版本对比链接指向相邻版本的 diff原文中的 compare 链接⚠ BREAKING CHANGES 段落标注破坏性变更通常伴随主版本号提升Features 段落功能新增最常见的是update the API跟随上游 API 定义重新生成客户端与run the generator重新运行代码生成器Bug Fixes 段落缺陷修复常见类型同样是update the API或依赖升级。该台账与模块的 package.json 严格同步——当前version字段为29.3.0与 CHANGELOG 最新条目一致。对使用者而言这份记录的价值在于它是判断升级到哪个版本、升级会不会破坏现有代码的第一手依据尤其是BREAKING CHANGES标记与 Node 运行时要求的变化。三、版本演进时间线从 0.2.0 到 29.3.0 的五年历程将 CHANGELOG 中的版本按时间排布可以清晰看到该模块的生命周期阶段代表性版本时间特征快速迭代期0.2.0 → 1.0.02021-04 ~ 2021-080.x 阶段高频update the API首版 1.0.0 于 2021-08-31 发布功能累积期2.x → 4.x2021-09 ~ 2022-06API 定义持续更新含多次破坏性变更生成器批量重跑期5.0.0 → 12.0.02022-10 ~ 2023-11大量run the generator条目如 #3161、#3355同一 API 定义被多批次重新生成稳定维护期13.0.0 → 15.4.02024-05 ~ 2025-04版本号跳跃15.0.0 同日连发三版与多次update the API运行时升级期16.0.0 → 18.0.02025-05 ~ 2025-09升级到 Node 18、googleapis-common 8.x高频刷新期21.x → 29.x2025-10 ~ 2026-10几乎每周一次update the API2026-09 完成 Node 22 最低版本迁移几个值得注意的历史细节2024-08-16 同日连发三版CHANGELOG 中 13.0.0、14.0.0、15.0.0 三个版本发布于同一天且都标注breaking changes并包含相同的两次update the API提交。这属于发布管道中常见的分批发布现象说明上游 API 在同一天发生了多次需要重新生成的变更。18.0.0 出现两次2025-08-21 与 2025-09-16 各有一个 18.0.0 条目前者由生成器触发后者伴随upgrade googleapis-common to 8.0.0。这是 release-please 在依赖升级与 API 更新并发时产生的主版本冲突从记录看最终以 19.0.0/20.0.0/21.0.0 接续推进。2026 年进入高频刷新期29.1.02026-10-03、29.2.02026-10-07、29.3.02026-10-14几乎以周为频率更新反映 Google 侧该 API 的后端定义仍在快速迭代。四、Node.js 运行时要求的三次跨越Node 12 → 18 → 22CHANGELOG 中反复出现的upgrade to node、Update apiary to minimum Node version等条目记录了这一模块最低 Node 版本的三次大迁移Node 122022-10-285.0.0条目run the generator (submodules now require Node 12)并标注为 BREAKING CHANGES对应上游 PR #3073。这是所有子模块统一将最低 Node 版本提升到 12。Node 182025-05-29 / 2025-06-3016.0.0 与 17.0.0 均以upgrade to node 18为 BREAKING CHANGES后者还附带将googleapis-common升级到8.0.2-rc。Node 222026-0926.0.02026-09-09、27.0.02026-09-10、28.0.02026-09-10均以Update apiary to minimum Node version of 22.作为 BREAKING CHANGES对应 PR #401129.0.02026-09-14进一步表述为Update apiary to minimum Node version of 22 again - all packagesPR #4020确认这是全仓库统一动作。过程中的一次回退插曲2026-09 的多条记录里同时出现了add back support for node 18如 25.1.1、26.0.0、27.0.0、28.0.0 条目与upgrade dependencies in generated packages to Node 22。从变更记录看团队在迁移到 Node 22 的过程中先临时为 Node 18 保留了兼容层随后在 28.0.0 中明确将生成包依赖升级到 Node 22最终由 29.0.0 定型为最低 Node 22。这一演进在源码中得到印证当前 package.json 中engines.node为22.0.0。如果你的运行环境低于 Node 22应选择 CHANGELOG 中 25.x 及更早的版本线或关注是否存在add back support的兼容版本。五、依赖演进googleapis-common 的版本轨迹googleapis-common是所有 API 子模块共享的基础库提供AuthPlus、createAPIRequest、getAPI等底层能力见 index.ts 的导入。CHANGELOG 记录了它的三次主要升级依赖版本出现于说明v710.2.22023-08-25与 11.0.0由 PR #3355 相关的依赖更新引入8.0.2-rc16.0.12025-06-04、17.0.0预发布候选版本伴随 Node 18 迁移8.0.017.1.12025-08-07、18.0.02025-09-16正式发布由 PR #3731 引入当前 package.json 中的依赖为googleapis-common: ^9.0.0说明在 CHANGELOG 覆盖周期之外该依赖又完成了一次主版本升级8 → 9。由于googleapis-common的主版本升级通常意味着底层请求封装与鉴权 API 的调整升级模块版本时务必同步关注对应版本条目的 Bug Fixes 段落中是否包含依赖升级记录避免新旧依赖混用导致运行期异常。六、update the API 与 run the generator持续集成的两大引擎统计 CHANGELOG 中 Features 与 Bug Fixes 条目绝大多数内容是两类机械性操作update the API表示上游 Google API 的 discovery 文档发生了变化仓库重新拉取 discovery/ondemandscanning-v1.json / discovery/ondemandscanning-v1beta1.json 并重新生成客户端使类型定义、请求参数与响应 Schema 跟随后端 API 同步演进。这类条目下通常看不到人类编写的代码改动但可能伴随新增/删除方法或字段因此被标记为 breaking changes 时需格外谨慎。run the generator指重新运行仓库内的代码生成器。从 src/generator/download.ts 的源码可以看出生成器会从discovery-artifact-manager拉取 index.json 与各 API 的 discovery 文档写入discovery/目录再据此生成src/apis/api/v*.ts等文件。CHANGELOG 中如run the generator (#3886)、run the generator (#3919)等条目见 21.2.0、22.0.0就是这类流水线动作的记录往往一次会波及所有 API 子模块。对使用者来说这两类条目意味着客户端是代码生成式的其类型系统天然跟随 Google 后端 API。当你看到新版本 CHANGELOG 只有update the API条目时升级主要是为了获得最新的 API 定义与类型只有当出现BREAKING CHANGES标注时才需要检查调用代码是否仍然兼容。七、源码解剖v1 客户端的资源层级与核心方法以 v1.ts 为例生成后的客户端结构非常清晰入口类Ondemandscanningv1.ts持有APIRequestContext并暴露顶层资源projects资源树projects → locations → { operations, scans }其中scans下还有vulnerabilitiesv1.ts核心方法scans.analyzePackagesv1.ts向POST https://ondemandscanning.googleapis.com/v1/{parent}/scans:analyzePackages发起请求返回Schema$Operation长时任务语义因为镜像漏洞分析耗时较长辅助方法operations.cancel/delete/get/list用于管理长时操作v1.tsscans.vulnerabilities.list用于拉取扫描出的漏洞列表。请求与响应的核心 Schema 在源码中有完整字段定义值得重点关注Schema$AnalyzePackagesRequestV1包含resourceUri必填被扫描的容器镜像资源 URI、packages要分析的软件包列表PackageData[]以及已废弃的includeOsvData字段注释明确说明为向后兼容而保留不能删除或改名Schema$PackageData描述单个软件包包含package、version、packageTypeos / maven / go 等、architecture、cpeUri、dependencyChain、fileLocation、hashDigestMaven 包的 SHA512等字段Schema$VulnerabilityOccurrence漏洞扫描结果包含cvssScore0–10、cvssV2/cvssv3/cvssV4、effectiveSeverity、fixAvailable、packageIssue受影响包与修复信息、riskCISA、EPSS 等风险信息、vexAssessment等字段。这些字段均来自 discovery 文档并经过 TypeScript 类型化意味着调用时可以获得完整的 IDE 智能提示与编译期校验。八、从 CHANGELOG 到实战安装、鉴权与发起一次扫描安装两种方式任选其一。方式一使用 monorepo 主包直接复用已有的googleapis依赖npm install googleapis方式二按需安装独立子包体积更小仅包含本 APInpm install googleapis/ondemandscanning鉴权与初始化On-Demand Scanning 需要访问 GCP 资源鉴权作用域为cloud-platform。模块内所有方法的示例代码见 v1.ts给出了标准初始化方式const {google} require(googleapis); const ondemandscanning google.ondemandscanning(v1); async function main() { const auth new google.auth.GoogleAuth({ scopes: [https://www.googleapis.com/auth/cloud-platform], }); const authClient await auth.getClient(); google.options({auth: authClient}); // 后续请求将自动携带鉴权信息 }发起扫描与拉取结果扫描流程是典型的提交长时任务 → 轮询操作状态 → 拉取结果三步// 1. 提交扫描返回 Operation const scan await ondemandscanning.projects.locations.scans.analyzePackages({ parent: projects/my-project/locations/my-location, requestBody: { resourceUri: gcr.io/my-project/my-image:latest, packages: [ { package: openssl, version: 1.1.1k, packageType: os, }, ], }, }); // scan.data 为 Schema$Operation其中包含 scan 资源名 // 2. 轮询操作直至完成亦可使用 operations.get const op await ondemandscanning.projects.locations.operations.get({ name: scan.data.name, }); // 3. 拉取该扫描命名的漏洞列表 const vulns await ondemandscanning.projects.locations.scans.vulnerabilities.list({ parent: projects/my-project/locations/my-location/scans/my-scan, }); // vulns.data 为 Schema$ListVulnerabilitiesResponseV1逐条包含 VulnerabilityOccurrence版本选择建议若需要最新 API 定义使用v1对应 discovery/ondemandscanning-v1.json若业务此前基于 v1beta1 对接且尚未迁移可继续使用google.ondemandscanning(v1beta1)但应关注 CHANGELOG 中的 breaking changes 以规划迁移当前主包默认使用与package.json一致的 29.3.0 版本线请确保运行环境满足 Node ≥ 22。九、如何利用 CHANGELOG 规划升级版本升级检查清单将这份 CHANGELOG 作为升级决策依据时建议按以下顺序检查定位 BREAKING CHANGES从目标版本回溯凡标注⚠ BREAKING CHANGES的版本如 29.0.0、28.0.0、17.0.0、5.0.0升级时需重点回归测试核对 Node 版本要求结合engines字段与 CHANGELOG 中的upgrade to node条目确认运行环境满足要求当前为 Node ≥ 22检查依赖变化googleapis-common等共享依赖的主版本升级v7 → 8 → 9可能与主包googleapis的依赖产生冲突需保持子包与主包版本匹配区分机械更新与实质变更仅含update the API/run the generator的版本如 29.1.0、29.2.0通常只是类型与定义刷新风险较低同时含有多个 breaking 标记的版本如 25.0.0、28.0.0则应视为重大升级核对源码中的实际接口升级后以 v1.ts 中的资源类与方法签名、package.json 的依赖清单为准确认调用代码所用方法仍然存在。小结ondemandscanning的 CHANGELOG 看似只是一长串版本号实则是这个生成式客户端工程运作方式的全景记录API 定义的持续更新、代码生成器的批量重跑、Node 运行时要求的三次跨越以及共享依赖的逐步升级都浓缩在每一条 Features 与 Bug Fixes 中。结合仓库内的 模块源码、package.json 与 生成器实现开发者可以准确判断每个版本的实际影响并在 Node ≥ 22 的环境下安全地使用最新客户端对容器镜像进行按需漏洞扫描。赞分享后端【免费下载链接】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 的 ondemandscanning 模块实战指南用 On-Demand Scanning API 扫描容器镜像漏洞google api nodejs client 的 ondemandscanning 模块实战指南用 On Demand Scanning API 扫描容器后端google-api-nodejs-client 中 firebasedataconnect 模块的版本演进CHANGELOG 全景解读google api nodejs client 中 firebasedataconnect 模块的版本演进CHANGELOG 全景解读 本文以 google后端google-api-nodejs-client netapp 模块全解析版本演进脉络与 NetApp Volumes API 实战google api nodejs client netapp 模块全解析版本演进脉络与 NetApp Volumes API 实战 NetApp Volum后端上一篇Whiteboard的Software Map实战为代码库绘制可交互的C4架构图下一篇免费AI资源大全awesome-free-models完全指南343条精选链接0成本玩转大模型创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考