资讯动态

Bare Metal Solution 客户端演进全解:从 @googleapis/baremetalsolution 变更日志看 Node.js 生态的版本迭代

发布时间:2026/10/15 21:37:10 来源:尧图企业网站定制
后端【免费下载链接】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点击查看免费下载导读src/apis/baremetalsolution/CHANGELOG.md记录了 google-api-nodejs-client 仓库中googleapis/baremetalsolution子包从 2023 年首发到 2026 年的完整版本演进史每次发版的时间点、破坏性变更BREAKING CHANGES、新特性与 Bug 修复一目了然。本文以该变更日志为主线骨架结合仓库中 baremetalsolution 包源码 与 package.json 等实现证据系统解读 Bare Metal Solution API 客户端在 Node.js 版本门槛、依赖升级和接口生成方面的演进逻辑帮助你理解该子包的版本策略并为升级、选型与迁移提供可验证的决策依据。一、这个子包是什么Bare Metal Solution API 的官方 Node.js 客户端Bare Metal Solution 是 Google Cloud 提供的裸金属托管服务用于在靠近 Google Cloud 数据中心区域的区域扩展点regional extension上部署和管理裸机硬件。googleapis/baremetalsolution正是 google-api-nodejs-client 仓库中针对该服务的自动生成子包。在源码层面index.ts 中明确注册了三个 API 版本export const VERSIONS { v1: baremetalsolution_v1.Baremetalsolution, v1alpha1: baremetalsolution_v1alpha1.Baremetalsolution, v2: baremetalsolution_v2.Baremetalsolution, };同时src/index.ts 与 src/apis/index.ts 将该子包挂载到整个googleapis聚合入口中这意味着你既可以通过聚合包googleapis使用google.baremetalsolution(v1|v1alpha1|v2)也可以单独安装googleapis/baremetalsolution独立使用。值得注意的是根据 README.md 的官方说明该子包目前处于维护模式maintenance mode——Google 会继续为已有存量应用提供支持但新应用建议改用云客户库 google-cloud/bare-metal-solution后者更快、更易用、维护更积极。这是评估该子包时最重要的背景信息之一。二、版本演进时间线三年 17 次发版全景变更日志完整记录了从 2023 年 8 月首发1.0.0到 2026 年 9 月9.0.1的全部版本。为便于纵览下表按时间顺序整理与变更日志的原始版本号顺序略有出入因为 1.x 与 2.x 的发布时间线存在交错版本发布日期类型核心内容1.0.02023-08-07首发update the API升级 googleapis-common 至 8.0.01.0.12023-08-13修复update the API升级 googleapis-common 至 8.0.01.0.22023-08-21修复update the API升级 googleapis-common 至 8.0.01.0.32023-08-25修复update the API升级 googleapis-common 至 8.0.01.0.42025-08-26修复update the API升级 googleapis-common 至 8.0.02.0.02025-05-29破坏性升级至 Node 182.0.12025-06-04修复升级 googleapis-common 至 8.0.2-rc3.0.02025-06-30破坏性升级至 Node 18googleapis-common 8.0.2-rc3.0.12025-07-08修复update the API4.0.02025-09-16破坏性releasing for our libraries (#3769)升级 googleapis-common 至 8.0.0 (#3731)5.0.02025-10-15破坏性run the generator (#3814)5.1.02026-09-02特性run the generator (#3992)升级依赖至 Node 225.1.12026-09-09修复恢复对 Node 18 的支持6.0.02026-09-09破坏性最低 Node 22 (#4011)run the generator恢复 Node 18 支持升级依赖至 Node 227.0.02026-09-10破坏性最低 Node 22 (#4011)恢复 Node 18 支持8.0.02026-09-10破坏性最低 Node 22 (#4011)run the generator恢复 Node 18 支持升级依赖至 Node 229.0.02026-09-14破坏性再次将 apiary 最低 Node 版本设为 22全部包#40209.0.12026-09-23修复update the API解读要点版本号并非单调递增的线性序列。1.x 与 2.x、3.x 之间存在时间交错如 1.0.4 发布于 2025-08晚于 2.0.0/3.0.0这是 release-please 多分支发版机制造成的正常现象升级时务必以发布日期和 CHANGELOG 条目为准。破坏性变更高度集中在两个主题Node.js 最低版本门槛抬升、以及 API 生成器generator重跑导致的接口刷新。2023 年之后存在近两年的静默期1.0.4 之前的 1.0.x 系列随后 2025 年中开始密集发版与 googleapis-common 8.x 的发布节奏见 CHANGELOG.md 多条记录高度同步。三、破坏性变更深度解读Node 版本门槛的三次抬升变更日志中所有⚠ BREAKING CHANGES条目几乎都指向同一件事——Node.js 最低版本要求。这可以拆成三个阶段阶段一升级到 Node 182025 年2.0.02025-05-29upgrade to node 183.0.02025-06-30再次upgrade to node 18并附带将依赖googleapis-common升级到8.0.2-rc阶段二升级到 Node 222026 年 9 月四连发2026 年 9 月 9 日至 10 日变更日志密集出现 4 个破坏性版本6.0.0、7.0.0、8.0.0 及 9.0.0统一主题为Update apiary to minimum Node version of 22对应仓库 issue #4011 与 #4020。有意思的是其中还出现了反复横跳8.0.0 与 7.0.0 的修复条目中写着add back support for node 18恢复 Node 18 支持说明该升级过程并非一步到位而是先由生成器抬升门槛、随后又针对旧版 Node 用户回补兼容最终在 9.0.0 中再次again将最低版本定为 Node 22。阶段三当前落地状态与变更日志相互印证的是当前仓库中 package.json 的实际声明engines: { node: 22.0.0 }也就是说截至本文写作时的仓库状态版本 9.0.1googleapis/baremetalsolution要求 Node.js 22。如果你的运行环境仍停留在 Node 18则只能锁定到 5.1.x 及更早的版本这一点对 CI 与生产环境的 Node 版本规划有直接影响。四、依赖演进googleapis-common 的三次升级变更日志中反复出现的另一个主题是基础库googleapis-common的升级它贯穿了几乎每一个版本时间点目标版本关联版本2023 年v71.0.x#9491ec12025-068.0.2-rc2.0.1、3.0.02025-08/098.0.01.0.1~1.0.4、4.0.0#3731当前^9.0.09.0.1package.json dependenciesgoogleapis-common是整个客户端库的引擎从 v1.ts 可以看到生成代码中的所有请求调度createAPIRequest、认证客户端OAuth2Client、JWT、Compute、GoogleAuth等、APIRequestContext、流式请求支持StreamMethodOptions、Readable全部来自该依赖。因此googleapis-common 的每次大版本升级都意味着请求层行为的潜在变化这也是变更日志将依赖升级与破坏性变更并列标注的原因——升级该子包时请一并关注 googleapis-common 的发布说明。五、从源码看三个 API 版本的资源差异变更日志只记录版本迭代而各版本 API 能力的差异需要结合生成源码确认。三个版本在 baremetalsolution 目录 下分别对应v1.ts、v1alpha1.ts、v2.ts资源结构差异明显v1极简的 operations 集合v1.ts 中Baremetalsolution类只挂载了一个资源export class Baremetalsolution { context: APIRequestContext; operations: Resource$Operations; ... }Resource$Operations提供 4 个方法cancel取消长期运行操作、delete删除操作、get查询操作状态、list按过滤条件列出操作请求路径统一指向https://baremetalsolution.googleapis.com/v1/见 v1.ts。从源码结构看v1 更接近一个占位级的早期接口。v2完整的资源树v2.ts 是当前主推版本体量达到 8599 行Baremetalsolution类下挂载projects资源形成完整的层级树projects └── locations ├── instanceprovisioningsettings (实例预配置设置) ├── instances (实例管理) ├── networks (网络管理) ├── nfsShares (NFS 共享) ├── operations (长时操作) ├── provisioningconfigs (预配置配置) ├── provisioningquotas (预配置配额) ├── sshKeys (SSH 密钥) └── volumes ├── luns (逻辑单元) └── snapshots (快照)对应的资源类定义在 v2.ts 中依次可见Resource$Projects、Resource$Projects$Locations、Resource$Projects$Locations$Instances、Resource$Projects$Locations$Networks、Resource$Projects$Locations$Nfsshares、Resource$Projects$Locations$Volumes、Resource$Projects$Locations$Volumes$Luns、Resource$Projects$Locations$Volumes$Snapshots等。这解释了为什么变更日志中 5.0.0 之后连续出现run the generator重跑生成器刷新接口——API 侧在持续扩展客户端必须同步。v1alpha1介于两者之间v1alpha1.ts 同样挂载projects资源树但从变更日志看它并不是发版的主线版本。选择版本时建议新项目优先使用 v2v1alpha1 仅在业务明确依赖 alpha 接口时考虑。六、安装与最小可用示例独立子包安装npm install googleapis/baremetalsolution该方式直接使用子包自身的入口 index.ts包版本号与变更日志一一对应当前 9.0.1见 package.json。聚合包方式npm install googleapis然后通过聚合入口挂载const {google} require(googleapis); const baremetalsolution google.baremetalsolution(v2);这一调用路径由 index.ts 的getAPI(baremetalsolution, versionOrOptions, VERSIONS, this)统一分派最终由googleapis-common的createAPIRequest完成 HTTP 请求。认证与调用示例生成源码中内置了可直接参考的示例。以 v2 的实例创建为例v2.ts 的projects.locations.instances.createconst {google} require(googleapis); const baremetalsolution google.baremetalsolution(v2); async function main() { const auth new google.auth.GoogleAuth({ // Scopes 可以数组或空格分隔字符串的形式指定 scopes: [https://www.googleapis.com/auth/cloud-platform], }); const authClient await auth.getClient(); google.options({auth: authClient}); const res await baremetalsolution.projects.locations.instances.create({ // 必填父项目与区域 parent: projects/my-project/locations/my-location, requestBody: { machineType: my_machineType, osImage: my_osImage, networkTemplate: my_networkTemplate, // 更多字段createTime、hyperthreadingEnabled、labels、 // logicalInterfaces、luns、networks、volumes、workloadProfile 等 }, }); console.log(res.data); } main().catch(e { console.error(e); throw e; });创建类操作返回的是标准长时操作Long-Running Operation响应done、error、metadata、name、response结构可通过projects.locations.operations.get轮询状态。该操作模型的字段定义可直接在 v1.ts 的Schema$Operation中查看done为false表示仍在进行中为true表示已完成且error或response可用。NFS 共享示例v2 的 NFS 共享创建接口同样内置完整示例v2.ts 的projects.locations.nfsShares.createconst res await baremetalsolution.projects.locations.nfsShares.create({ parent: projects/my-project/locations/my-location, requestBody: { allowedClients: [], requestedSizeGib: my_requestedSizeGib, storageType: my_storageType, volume: my_volume, // 其他字段id、labels、name、nfsShareId、state }, });其中的allowedClients数组元素由Schema$AllowedClient定义v2.ts包含访问控制的关键字段allowedClientsCidr允许访问共享的 IP 子网、mountPermissions挂载权限、allowDev是否允许创建设备、allowSuid是否允许 setuid 标志、noRootSquash是否禁用 NFS 的 root 压缩等。七、升级与迁移实操建议综合变更日志与仓库现状针对不同场景给出可执行建议场景一新项目接入优先使用 v2 版本它拥有完整的实例、网络、NFS、卷、快照资源体系遵循 README 指引评估直接采用google-cloud/bare-metal-solution云客户库因为googleapis/baremetalsolution已进入维护模式新功能迭代放缓运行环境需满足 Node.js 22当前 engines 声明。场景二存量项目升级先核对 Node 版本若运行在 Node 18升级到 9.x 将触发破坏性变更建议先升级运行时再升级依赖关注依赖传递googleapis-common从 8.x 升到 9.x 属于大版本升级升级后建议回归验证所有 baremetalsolution 相关调用路径版本跳变谨慎由于 1.x 与 2.x 时间线交错升级时不要按版本号大小盲目跳升应参考变更日志按发布日期逐步推进接口刷新run the generator类条目如 5.0.0、5.1.0、6.0.0、8.0.0意味着接口定义被重新生成升级后可能新增/调整资源方法请对照新版 v2.ts 的 TypeScript 类型签名修正调用代码。结语googleapis/baremetalsolution的变更日志虽然只是一份版本记录但它完整呈现了一个官方生成型客户端子包的典型生命周期从 2023 年首发时的极简operations接口到 v2 的完整资源树从 Node 18 到 Node 22 的门槛抬升再到googleapis-common依赖的三轮大版本升级。理解这些版本演进的规律既能帮助你在升级时规避破坏性变更也能让你在选型时做出更清醒的判断——尤其是维护模式这一官方定位应当成为任何新项目决策时最先考虑的因素。赞分享后端【免费下载链接】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点击查看免费下载相关推荐googleapis/apigateway 版本演进全解析从 CHANGELOG 看 API Gateway Node.js 客户端googleapis/apigateway 版本演进全解析从 CHANGELOG 看 API Gateway Node.js 客户端 本文以 google后端googleapis/datacatalog 版本演进全解析从 CHANGELOG 看 Data Catalog Node.js 客户端三年变迁googleapis/datacatalog 版本演进全解析从 CHANGELOG 看 Data Catalog Node.js 客户端三年变迁 本篇以 d后端googleapis/blogger 版本演进全解读从 v0.1 到 v12 的变更日志与源码验证googleapis/blogger 版本演进全解读从 v0.1 到 v12 的变更日志与源码验证 本文以 src/apis/blogger/CHANGEL后端创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑