后端DevOps云原生微服务【免费下载链接】spinnakerSpinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence.项目地址https://gitcode.com/gh_mirrors/sp/spinnaker点击查看免费下载spinnaker/pluginsdk-peerdeps是 Spinnaker Deck 前端仓库中专门面向插件开发者发布的依赖清单包它以一份携带peerDependencies与peerDependenciesMeta的package.json告知 Deck 插件应当安装哪些版本的 React、Rollup、TypeScript 与 Spinnaker 内部库。本文基于该包的 CHANGELOG.md结合包内 package.json、README.md 以及两个同步脚本源码完整梳理该包的定位、依赖同步机制、升级工作流与 2022 至 2024 年的全部版本演进历史帮助插件开发者理解并维护与 Deck 主版本保持一致的依赖基线。一、包定位插件依赖的权威清单从源码结构看spinnaker/pluginsdk-peerdeps是一个元数据型包它自身几乎不包含可执行代码package.json中files为空数组核心资产就是声明了约 33 个 peer 依赖及其可选元信息的两段 JSON 字段。README.md 明确说明Deck 插件应当声明对spinnaker/pluginsdk-peerdeps的依赖包内的peerDependencies与peerDependenciesMeta字段会告知插件应使用哪个版本的 React、Rollup、TypeScript 等包供check-peer-dependencies这类工具校验实际安装结果。以当前仓库中的 package.json版本 0.21.0为例其peerDependencies完整清单如下包名版本约束包名版本约束rollup/plugin-commonjs^28.0.9npm-run-all25.0.0rollup/plugin-json^6.1.0postcss^8.4.14rollup/plugin-node-resolve^16.0.0prettier2.1.2rollup/plugin-replace^6.0.3pretty-quick^3.1.0rollup/plugin-typescript^12.3.0prop-types15.6.1rollup/plugin-url^8.0.2react~16.14.0spinnaker/core0.29.1react-dom~16.14.0spinnaker/eslint-plugin3.0.2rollup^4.59.0spinnaker/pluginsdk*rollup-plugin-external-globals^0.13.0spinnaker/presentation0.3.1rollup-plugin-less1.1.3types/react~16.8.0rollup-plugin-postcss^4.0.2uirouter/core6.0.8rollup-plugin-visualizer^5.14.0uirouter/react1.0.7rxjs6.6.7bufferutil4.0.9shx0.3.3lodash-es4.18.1typescript5.0.4utf-8-validate5.0.10这些依赖分为两类一类是 React 16 生态、uirouter路由与 Rollup 打包链等运行/构建期依赖另一类是 Spinnaker 自有包spinnaker/core、spinnaker/eslint-plugin、spinnaker/presentation它们与 Deck 主 UI 的版本严格绑定。peerDependenciesMeta中则将rollup/*系列插件、rollup、typescript、prettier、types/react、bufferutil、utf-8-validate、shx、postcss、npm-run-all2、pretty-quick、rollup-plugin-*等标记为dev: true表示这些包属于插件构建/校验工具链而非运行时依赖——这一点是后续双向转换脚本区分依赖类型的依据。插件侧的实际消费入口是spinnaker/pluginsdk的校验器 lint.package.json.jscheck-plugin通过npm info查询最新发布的spinnaker/pluginsdk-peerdeps版本与插件package.json中实际安装的版本比对若不匹配则输出告警与修复命令pnpm add spinnaker/pluginsdk-peerdepslatest同时该校验器还会强制插件遵循postinstall: check-plugin check-peer-dependencies || true等脚本约定确保check-peer-dependencies声明在 pluginsdk 的 dependencies 中在安装后自动核对 peer 依赖的版本一致性。二、peerdep-sync从 Deck 根 package.json 同步版本的自动化机制CHANGELOG 中几乎每一次版本发布都标注为peerdep-sync: Synchronize peerdependencies这正是该包最主要的变更类型。其自动化入口是 package.json 中的 scriptsscripts: { temp: ./convert-peerdeps.js --from-peerdeps --input package.json --output package.temp.json, restoretemp: ./convert-peerdeps.js --to-peerdeps --output package.json --input package.temp.json rm package.temp.json, copyDeck: ./sync-versions-from-deck.js --source ../../package.json --dest package.temp.json --no-peer --no-dev, sync: npm run temp npm run copyDeck npm run restoretemp, interactive: ./upgrade-interactive.sh }整个pnpm sync流程分三步temp调用convert-peerdeps.js --from-peerdeps把当前以peerDependencies形态存在的依赖先还原成普通package.json的dependencies/devDependencies形态输出到临时文件package.temp.jsoncopyDeck调用 sync-versions-from-deck.js以 Deck 根目录 package.json 为版本权威来源把临时文件中的依赖版本全部更新为 Deck 当前使用的版本此步骤用--no-peer --no-dev跳过对依赖类型的改动只改写版本号restoretemp调用convert-peerdeps.js --to-peerdeps把更新完版本的临时文件再转换回peerDependencies形态写回正式package.json。sync-versions-from-deck.js 的核心逻辑如下读取 Deck 根package.json的peerDependencies、devDependencies、dependencies三部分合并成versionsFromDeck映射作为版本真值表对三个 Spinnaker 内部包做特殊处理spinnaker/core、spinnaker/eslint-plugin、spinnaker/presentation不从根package.json取版本而是分别解析../core/package.json、../eslint-plugin/package.json、../presentation/package.json中的version字段保证与 Deck 各包自身的发布版本严格一致遍历目标package.json的dependencies/peerDependencies/devDependencies三个键逐个把已存在的包版本改写为期望版本若versionsFromDeck中查不到例如spinnaker/pluginsdk用*通配则保留原值提供--no-dev、--no-peer、--no-spinnaker跳过spinnaker/*包三个开关供按需过滤。这段源码解释了 CHANGELOG 中版本号密集、几乎每月一版的现象只要 Deck 根package.json的任一依赖版本更新执行一次pnpm sync便会触发一次peerdep-sync提交从而发布一个新版本号让所有插件能及时对齐 Deck 的依赖基线。三、双向转换工具 convert-peerdeps.jsconvert-peerdeps.js 是实现普通 package.json 与 peerdeps 形态 package.json 互相转换的命令行工具也是sync与交互式升级流程的基础设施。它基于yargs提供以下参数参数说明--to-peerdeps将普通package.json转换为 peerdeps 形态dependenciesdevDependencies合并进peerDependencies--from-peerdeps将 peerdeps 形态的package.json还原为普通形态依据peerDependenciesMeta中的dev: true拆分为devDependencies与dependencies--input/--output输入/输出文件省略时默认使用 STDIN/STDOUT官方示例用法# 普通 package.json 转为 peerdeps 形态 ./convert-peerdeps.js --to-peerdeps ./package.json package.peerdeps.json # 指定输入输出文件 ./convert-peerdeps.js --to-peerdeps --input ./package.json --output package.peerdeps.json # peerdeps 形态还原为普通 package.json ./convert-peerdeps.js --from-peerdeps --input package.peerdeps.json package.json转换规则值得注意to-peerdeps 方向dependencies与devDependencies合并写入peerDependencies并按包名排序原devDependencies中的每个包在peerDependenciesMeta中标记为{ dev: true }。这意味着开发期工具链与插件运行依赖的边界被保留在peerDependenciesMeta中而不是被抹平from-peerdeps 方向读取peerDependenciesMeta中所有dev: true的包名集合用lodash的partition将peerDependencies拆回devDependencies工具链与dependencies运行时依赖两个方向都只对dependencies、devDependencies、peerDependencies、peerDependenciesMeta四个字段做搬运其余字段name、version、scripts等原样保留因此转换是无损的。四、交互式升级容器化的版本提升工作流除了全量同步CHANGELOG 之外的仓库还提供了一条交互式升级路径。pnpm interactive对应的 upgrade-interactive.sh 会构建并运行一个 Docker 容器docker build -f Dockerfile.upgrade-interactive . -t spinnaker-deck-plugin-peerdeps-upgrade docker run -v $PWD:/mnt/pluginsdk-peerdeps -it spinnaker-deck-plugin-peerdeps-upgrade:latestDockerfile.upgrade-interactive 基于alpine安装nodejs与yarn复制convert-peerdeps.js并安装其依赖lodash、yargs随后在容器启动时执行以下流水线从挂载目录/mnt/pluginsdk-peerdeps复制package.json到容器工作区用convert-peerdeps.js --from-peerdeps将 peerdeps 形态还原为普通package.json便于 yarn 识别并管理依赖执行yarn安装依赖执行yarn upgrade-interactive --latest打开交互式选择界面由维护者逐个挑选要升级的包与目标版本用convert-peerdeps.js --to-peerdeps将升级后的依赖重新打包回 peerdeps 形态将结果package.json复制回宿主机挂载目录完成一次交互式版本提升。对比可知pnpm sync是以 Deck 根 package.json 为准的批量对齐适合常规同步而容器化交互式升级则面向需要人工决定个别包是否跟随最新版的场景且通过 Docker 隔离避免了宿主机 Node/yarn 环境差异。五、完整版本历史与演进节奏以下版本记录完整继承自 CHANGELOG.md按时间倒序列出全部 22 个发布版本发布日期类型变更内容0.21.02024-06-10Featurespeerdep-sync同步 peer 依赖0.20.02024-05-10Featurespeerdep-sync同步 peer 依赖0.19.02023-12-07Featurespeerdep-sync同步 peer 依赖0.18.02023-10-16Featurespeerdep-sync同步 peer 依赖0.17.12023-10-16Bug Fixes为 Deck 库设置发布 access 配置对应 issue #100490.17.02023-09-06Featurespeerdep-sync同步 peer 依赖0.16.02023-07-20Featurespeerdep-sync同步 peer 依赖0.15.02023-06-02Featurespeerdep-sync同步 peer 依赖0.14.02023-05-11Featurespeerdep-sync同步 peer 依赖0.13.02023-05-03Featurespeerdep-sync同步 peer 依赖0.12.02023-05-01Featurespeerdep-sync同步 peer 依赖0.11.02023-04-03Featurespeerdep-sync同步 peer 依赖0.10.02023-03-15Featurespeerdep-sync同步 peer 依赖0.9.02023-02-20Featurespeerdep-sync同步 peer 依赖0.8.02023-02-07Featurespeerdep-sync同步 peer 依赖0.7.02023-02-02Featurespeerdep-sync同步 peer 依赖0.6.02023-02-01Featurespeerdep-sync同步 peer 依赖0.5.02022-10-21Featurespeerdep-sync同步 peer 依赖0.4.02022-10-06Featurespeerdep-sync同步 peer 依赖0.3.02022-08-25Featurespeerdep-sync同步 peer 依赖0.2.02022-08-03Featurespeerdep-sync同步 peer 依赖0.1.02022-08-03Featuresdependencies更新存在安全漏洞的依赖对应 issue #9875从这份历史可以读出几个关键信息发布节奏与 Deck 主仓库同步2022 年 8 月至 2024 年 6 月共发布 22 个版本其中 2023 年 2 月甚至在一个月内连发 0.6.0、0.7.0、0.8.0 三个版本与 Deck 依赖频繁升级的节奏吻合绝大多数变更为peerdep-sync这与第二节描述的pnpm sync脚本机制一一对应说明该包的版本号本质上是Deck 依赖基线版本的镜像两个非同步变更值得关注0.1.0是一次安全驱动的依赖升级修复存在漏洞的依赖0.17.1则修复了 Deck 库发布时的 access 配置问题——后者从 package.json 中的publishConfig.access: public可以得到印证即该包作为面向插件开发者公开发布的 npm 包必须确保发布配置正确否则插件无法拉取到依赖清单。六、插件开发者如何消费这套依赖治理综合以上机制插件开发者与 Deck 依赖基线保持一致的完整链路是声明对清单包的依赖在插件package.json中安装spinnaker/pluginsdk-peerdeps并在postinstall脚本中串联check-plugin与check-peer-dependencies该约定由 lint.package.json.js 强制校验让check-peer-dependencies依据清单中的peerDependencies自动校验插件实际安装的 React、Rollup、TypeScript 等版本关注版本发布由于该包几乎每次发布都对应 Deck 依赖的一次同步插件侧应及时跟进最新版本0.21.0为当前仓库中的最新版本避免构建工具链与 Deck 主 UI 产生版本漂移理解依赖分层peerDependenciesMeta中dev: true标记的构建工具链包与运行时依赖在安装策略上不同插件安装工具链时不需要与宿主 Deck 共享实例而spinnaker/core、react、uirouter/*等运行期包则需要与 Deck 保持一致这正是清单包设计的核心目的。对于需要维护该包本身的开发者仓库提供了两条已验证的路径日常使用pnpm sync对应temp→copyDeck→restoretemp三步脚本批量对齐 Deck 根package.json需要对个别依赖做人工抉择时使用pnpm interactive启动容器化交互式升级。两条路径都以 convert-peerdeps.js 与 sync-versions-from-deck.js 为底层实现且都保证最终产物是只有peerDependenciespeerDependenciesMeta的精简清单包这一形态。赞分享后端DevOps云原生微服务【免费下载链接】spinnakerSpinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence.项目地址https://gitcode.com/gh_mirrors/sp/spinnaker点击查看免费下载相关推荐Spinnaker Deck spinnaker/google 包版本演进与 GCE 提供商核心功能解析2018-2024Spinnaker Deck spinnaker/google 包版本演进与 GCE 提供商核心功能解析2018 2024 本篇技术指南以 deck/pa后端DevOps云原生微服务spinnaker/eslint-plugin 演进解读Spinnaker Deck 前端 ESLint 规则体系的版本历程与实战指南spinnaker/eslint plugin 演进解读Spinnaker Deck 前端 ESLint 规则体系的版本历程与实战指南 导读 本文以 dec后端DevOps云原生微服务Video2X 视频超分辨率与插帧老片复活到 4K 的免费本地指南Video2X 视频超分辨率与插帧老片复活到 4K 的免费本地指南 手里有一段 480p 老动漫想拉回高清又怕传网盘Video2X 的视频超分辨率和插帧一音视频视频处理图像处理深度学习创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Spinnaker Deck 插件依赖治理：@spinnaker/pluginsdk-peerdeps 的版本演进与同步机制
后端DevOps云原生微服务【免费下载链接】spinnakerSpinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence.项目地址https://gitcode.com/gh_mirrors/sp/spinnaker点击查看免费下载spinnaker/pluginsdk-peerdeps是 Spinnaker Deck 前端仓库中专门面向插件开发者发布的依赖清单包它以一份携带peerDependencies与peerDependenciesMeta的package.json告知 Deck 插件应当安装哪些版本的 React、Rollup、TypeScript 与 Spinnaker 内部库。本文基于该包的 CHANGELOG.md结合包内 package.json、README.md 以及两个同步脚本源码完整梳理该包的定位、依赖同步机制、升级工作流与 2022 至 2024 年的全部版本演进历史帮助插件开发者理解并维护与 Deck 主版本保持一致的依赖基线。一、包定位插件依赖的权威清单从源码结构看spinnaker/pluginsdk-peerdeps是一个元数据型包它自身几乎不包含可执行代码package.json中files为空数组核心资产就是声明了约 33 个 peer 依赖及其可选元信息的两段 JSON 字段。README.md 明确说明Deck 插件应当声明对spinnaker/pluginsdk-peerdeps的依赖包内的peerDependencies与peerDependenciesMeta字段会告知插件应使用哪个版本的 React、Rollup、TypeScript 等包供check-peer-dependencies这类工具校验实际安装结果。以当前仓库中的 package.json版本 0.21.0为例其peerDependencies完整清单如下包名版本约束包名版本约束rollup/plugin-commonjs^28.0.9npm-run-all25.0.0rollup/plugin-json^6.1.0postcss^8.4.14rollup/plugin-node-resolve^16.0.0prettier2.1.2rollup/plugin-replace^6.0.3pretty-quick^3.1.0rollup/plugin-typescript^12.3.0prop-types15.6.1rollup/plugin-url^8.0.2react~16.14.0spinnaker/core0.29.1react-dom~16.14.0spinnaker/eslint-plugin3.0.2rollup^4.59.0spinnaker/pluginsdk*rollup-plugin-external-globals^0.13.0spinnaker/presentation0.3.1rollup-plugin-less1.1.3types/react~16.8.0rollup-plugin-postcss^4.0.2uirouter/core6.0.8rollup-plugin-visualizer^5.14.0uirouter/react1.0.7rxjs6.6.7bufferutil4.0.9shx0.3.3lodash-es4.18.1typescript5.0.4utf-8-validate5.0.10这些依赖分为两类一类是 React 16 生态、uirouter路由与 Rollup 打包链等运行/构建期依赖另一类是 Spinnaker 自有包spinnaker/core、spinnaker/eslint-plugin、spinnaker/presentation它们与 Deck 主 UI 的版本严格绑定。peerDependenciesMeta中则将rollup/*系列插件、rollup、typescript、prettier、types/react、bufferutil、utf-8-validate、shx、postcss、npm-run-all2、pretty-quick、rollup-plugin-*等标记为dev: true表示这些包属于插件构建/校验工具链而非运行时依赖——这一点是后续双向转换脚本区分依赖类型的依据。插件侧的实际消费入口是spinnaker/pluginsdk的校验器 lint.package.json.jscheck-plugin通过npm info查询最新发布的spinnaker/pluginsdk-peerdeps版本与插件package.json中实际安装的版本比对若不匹配则输出告警与修复命令pnpm add spinnaker/pluginsdk-peerdepslatest同时该校验器还会强制插件遵循postinstall: check-plugin check-peer-dependencies || true等脚本约定确保check-peer-dependencies声明在 pluginsdk 的 dependencies 中在安装后自动核对 peer 依赖的版本一致性。二、peerdep-sync从 Deck 根 package.json 同步版本的自动化机制CHANGELOG 中几乎每一次版本发布都标注为peerdep-sync: Synchronize peerdependencies这正是该包最主要的变更类型。其自动化入口是 package.json 中的 scriptsscripts: { temp: ./convert-peerdeps.js --from-peerdeps --input package.json --output package.temp.json, restoretemp: ./convert-peerdeps.js --to-peerdeps --output package.json --input package.temp.json rm package.temp.json, copyDeck: ./sync-versions-from-deck.js --source ../../package.json --dest package.temp.json --no-peer --no-dev, sync: npm run temp npm run copyDeck npm run restoretemp, interactive: ./upgrade-interactive.sh }整个pnpm sync流程分三步temp调用convert-peerdeps.js --from-peerdeps把当前以peerDependencies形态存在的依赖先还原成普通package.json的dependencies/devDependencies形态输出到临时文件package.temp.jsoncopyDeck调用 sync-versions-from-deck.js以 Deck 根目录 package.json 为版本权威来源把临时文件中的依赖版本全部更新为 Deck 当前使用的版本此步骤用--no-peer --no-dev跳过对依赖类型的改动只改写版本号restoretemp调用convert-peerdeps.js --to-peerdeps把更新完版本的临时文件再转换回peerDependencies形态写回正式package.json。sync-versions-from-deck.js 的核心逻辑如下读取 Deck 根package.json的peerDependencies、devDependencies、dependencies三部分合并成versionsFromDeck映射作为版本真值表对三个 Spinnaker 内部包做特殊处理spinnaker/core、spinnaker/eslint-plugin、spinnaker/presentation不从根package.json取版本而是分别解析../core/package.json、../eslint-plugin/package.json、../presentation/package.json中的version字段保证与 Deck 各包自身的发布版本严格一致遍历目标package.json的dependencies/peerDependencies/devDependencies三个键逐个把已存在的包版本改写为期望版本若versionsFromDeck中查不到例如spinnaker/pluginsdk用*通配则保留原值提供--no-dev、--no-peer、--no-spinnaker跳过spinnaker/*包三个开关供按需过滤。这段源码解释了 CHANGELOG 中版本号密集、几乎每月一版的现象只要 Deck 根package.json的任一依赖版本更新执行一次pnpm sync便会触发一次peerdep-sync提交从而发布一个新版本号让所有插件能及时对齐 Deck 的依赖基线。三、双向转换工具 convert-peerdeps.jsconvert-peerdeps.js 是实现普通 package.json 与 peerdeps 形态 package.json 互相转换的命令行工具也是sync与交互式升级流程的基础设施。它基于yargs提供以下参数参数说明--to-peerdeps将普通package.json转换为 peerdeps 形态dependenciesdevDependencies合并进peerDependencies--from-peerdeps将 peerdeps 形态的package.json还原为普通形态依据peerDependenciesMeta中的dev: true拆分为devDependencies与dependencies--input/--output输入/输出文件省略时默认使用 STDIN/STDOUT官方示例用法# 普通 package.json 转为 peerdeps 形态 ./convert-peerdeps.js --to-peerdeps ./package.json package.peerdeps.json # 指定输入输出文件 ./convert-peerdeps.js --to-peerdeps --input ./package.json --output package.peerdeps.json # peerdeps 形态还原为普通 package.json ./convert-peerdeps.js --from-peerdeps --input package.peerdeps.json package.json转换规则值得注意to-peerdeps 方向dependencies与devDependencies合并写入peerDependencies并按包名排序原devDependencies中的每个包在peerDependenciesMeta中标记为{ dev: true }。这意味着开发期工具链与插件运行依赖的边界被保留在peerDependenciesMeta中而不是被抹平from-peerdeps 方向读取peerDependenciesMeta中所有dev: true的包名集合用lodash的partition将peerDependencies拆回devDependencies工具链与dependencies运行时依赖两个方向都只对dependencies、devDependencies、peerDependencies、peerDependenciesMeta四个字段做搬运其余字段name、version、scripts等原样保留因此转换是无损的。四、交互式升级容器化的版本提升工作流除了全量同步CHANGELOG 之外的仓库还提供了一条交互式升级路径。pnpm interactive对应的 upgrade-interactive.sh 会构建并运行一个 Docker 容器docker build -f Dockerfile.upgrade-interactive . -t spinnaker-deck-plugin-peerdeps-upgrade docker run -v $PWD:/mnt/pluginsdk-peerdeps -it spinnaker-deck-plugin-peerdeps-upgrade:latestDockerfile.upgrade-interactive 基于alpine安装nodejs与yarn复制convert-peerdeps.js并安装其依赖lodash、yargs随后在容器启动时执行以下流水线从挂载目录/mnt/pluginsdk-peerdeps复制package.json到容器工作区用convert-peerdeps.js --from-peerdeps将 peerdeps 形态还原为普通package.json便于 yarn 识别并管理依赖执行yarn安装依赖执行yarn upgrade-interactive --latest打开交互式选择界面由维护者逐个挑选要升级的包与目标版本用convert-peerdeps.js --to-peerdeps将升级后的依赖重新打包回 peerdeps 形态将结果package.json复制回宿主机挂载目录完成一次交互式版本提升。对比可知pnpm sync是以 Deck 根 package.json 为准的批量对齐适合常规同步而容器化交互式升级则面向需要人工决定个别包是否跟随最新版的场景且通过 Docker 隔离避免了宿主机 Node/yarn 环境差异。五、完整版本历史与演进节奏以下版本记录完整继承自 CHANGELOG.md按时间倒序列出全部 22 个发布版本发布日期类型变更内容0.21.02024-06-10Featurespeerdep-sync同步 peer 依赖0.20.02024-05-10Featurespeerdep-sync同步 peer 依赖0.19.02023-12-07Featurespeerdep-sync同步 peer 依赖0.18.02023-10-16Featurespeerdep-sync同步 peer 依赖0.17.12023-10-16Bug Fixes为 Deck 库设置发布 access 配置对应 issue #100490.17.02023-09-06Featurespeerdep-sync同步 peer 依赖0.16.02023-07-20Featurespeerdep-sync同步 peer 依赖0.15.02023-06-02Featurespeerdep-sync同步 peer 依赖0.14.02023-05-11Featurespeerdep-sync同步 peer 依赖0.13.02023-05-03Featurespeerdep-sync同步 peer 依赖0.12.02023-05-01Featurespeerdep-sync同步 peer 依赖0.11.02023-04-03Featurespeerdep-sync同步 peer 依赖0.10.02023-03-15Featurespeerdep-sync同步 peer 依赖0.9.02023-02-20Featurespeerdep-sync同步 peer 依赖0.8.02023-02-07Featurespeerdep-sync同步 peer 依赖0.7.02023-02-02Featurespeerdep-sync同步 peer 依赖0.6.02023-02-01Featurespeerdep-sync同步 peer 依赖0.5.02022-10-21Featurespeerdep-sync同步 peer 依赖0.4.02022-10-06Featurespeerdep-sync同步 peer 依赖0.3.02022-08-25Featurespeerdep-sync同步 peer 依赖0.2.02022-08-03Featurespeerdep-sync同步 peer 依赖0.1.02022-08-03Featuresdependencies更新存在安全漏洞的依赖对应 issue #9875从这份历史可以读出几个关键信息发布节奏与 Deck 主仓库同步2022 年 8 月至 2024 年 6 月共发布 22 个版本其中 2023 年 2 月甚至在一个月内连发 0.6.0、0.7.0、0.8.0 三个版本与 Deck 依赖频繁升级的节奏吻合绝大多数变更为peerdep-sync这与第二节描述的pnpm sync脚本机制一一对应说明该包的版本号本质上是Deck 依赖基线版本的镜像两个非同步变更值得关注0.1.0是一次安全驱动的依赖升级修复存在漏洞的依赖0.17.1则修复了 Deck 库发布时的 access 配置问题——后者从 package.json 中的publishConfig.access: public可以得到印证即该包作为面向插件开发者公开发布的 npm 包必须确保发布配置正确否则插件无法拉取到依赖清单。六、插件开发者如何消费这套依赖治理综合以上机制插件开发者与 Deck 依赖基线保持一致的完整链路是声明对清单包的依赖在插件package.json中安装spinnaker/pluginsdk-peerdeps并在postinstall脚本中串联check-plugin与check-peer-dependencies该约定由 lint.package.json.js 强制校验让check-peer-dependencies依据清单中的peerDependencies自动校验插件实际安装的 React、Rollup、TypeScript 等版本关注版本发布由于该包几乎每次发布都对应 Deck 依赖的一次同步插件侧应及时跟进最新版本0.21.0为当前仓库中的最新版本避免构建工具链与 Deck 主 UI 产生版本漂移理解依赖分层peerDependenciesMeta中dev: true标记的构建工具链包与运行时依赖在安装策略上不同插件安装工具链时不需要与宿主 Deck 共享实例而spinnaker/core、react、uirouter/*等运行期包则需要与 Deck 保持一致这正是清单包设计的核心目的。对于需要维护该包本身的开发者仓库提供了两条已验证的路径日常使用pnpm sync对应temp→copyDeck→restoretemp三步脚本批量对齐 Deck 根package.json需要对个别依赖做人工抉择时使用pnpm interactive启动容器化交互式升级。两条路径都以 convert-peerdeps.js 与 sync-versions-from-deck.js 为底层实现且都保证最终产物是只有peerDependenciespeerDependenciesMeta的精简清单包这一形态。赞分享后端DevOps云原生微服务【免费下载链接】spinnakerSpinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence.项目地址https://gitcode.com/gh_mirrors/sp/spinnaker点击查看免费下载相关推荐Spinnaker Deck spinnaker/google 包版本演进与 GCE 提供商核心功能解析2018-2024Spinnaker Deck spinnaker/google 包版本演进与 GCE 提供商核心功能解析2018 2024 本篇技术指南以 deck/pa后端DevOps云原生微服务spinnaker/eslint-plugin 演进解读Spinnaker Deck 前端 ESLint 规则体系的版本历程与实战指南spinnaker/eslint plugin 演进解读Spinnaker Deck 前端 ESLint 规则体系的版本历程与实战指南 导读 本文以 dec后端DevOps云原生微服务Video2X 视频超分辨率与插帧老片复活到 4K 的免费本地指南Video2X 视频超分辨率与插帧老片复活到 4K 的免费本地指南 手里有一段 480p 老动漫想拉回高清又怕传网盘Video2X 的视频超分辨率和插帧一音视频视频处理图像处理深度学习创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考