Storybook upgrade 命令实战一次同步全部 storybook/* 包从技能脚本到源码级实现【免费下载链接】storybookStorybook is the industry standard workshop for building, documenting, and testing UI components in isolation项目地址: https://gitcode.com/GitHub_Trending/st/storybook本篇技术指南以 Storybook 仓库中的storybook-upgrade技能文档为核心完整讲解npx storybookVERSION upgrade的用法、canary 版本号规约并结合 upgrade.ts 等源码深入剖析 upgrade 命令的项目检测、依赖解析、自动迁移与健康检查流程。读完本文你将掌握在外部应用、复现项目或测试项目中把 Storybook 精确升级到指定版本release 或 canary的完整方案并理解一次只升一个大版本这条铁律在源码层面是如何被强制执行的。技能定位为什么需要升级到指定版本的专门工作流storybook-upgrade 技能实际内容位于 .agents/skills/storybook-upgrade/SKILL.md的原始用途写得非常明确它主要用于在本仓库之外验证 Storybook 的变更典型场景有二在下游应用中QA 某个 Storybook PR 的 canary 构建Upgrade a canary build from a Storybook PR在外部项目中复现或验证某个 bug。这两类场景与常见的把 Storybook 升到最新稳定版不同目标版本往往是一个随 PR 动态生成的 canary 版本号或某个历史 release例如回到 8.5.0 做对照测试。技能文档给出的标准命令只有一行npx storybookVERSION upgrade其中VERSION可以是三种形态技能文档分别给出了可复制的示例升级到 canary 版本npx storybook0.0.0-pr-33526-sha-a2e09fa2 upgrade升级到最新稳定版npx storybooklatest upgrade升级到指定 releasenpx storybook8.5.0 upgrade这种通过npx storybookversion指定 CLI 自身版本、再执行 upgrade的写法是关键技巧npx 会临时拉取该版本的storybook/cli由它按自己的版本逻辑去改写你项目里的全部 Storybook 依赖从而保证 CLI 版本与目标依赖版本一致。Canary 版本号解码0.0.0-pr-PR号-sha-短SHA技能文档示例中的0.0.0-pr-33526-sha-a2e09fa2不是随意编造的。配套的 canary 发布技能 说明了其生成规则GitHub Actions 会把 PR 构建并出版本号为0.0.0-pr-PR_NUMBER-sha-SHORT_SHA的包并打上canarytag其中PR_NUMBER是 PR 编号如33526SHORT_SHA是该 PR 最新 commit SHA 的前 8 位如a2e09fa2。也就是说只要知道 PR 号和最新 commit就可以自行拼出这个版本号。源码层面upgrade 命令对这类版本号有专门的识别逻辑。util.ts 中的isCanaryVersion函数判定以0.0.0开头的版本为 canary同时兼容portal:/workspace:前缀的本地/私有版本const isCanaryVersion (version: string): boolean version.startsWith(0.0.0) || version.startsWith(portal:) || version.startsWith(workspace:);这个判定直接影响后续行为——canary 升级会跳过降级校验见下文因为0.0.0-pr-*这种 pre-release 版本号在语义化版本比较中天然小于一切正式版本若不做特判会被误判为降级。upgrade 命令实际做了什么源码级流程拆解技能文档声称 upgrade 命令会做四件事检测项目中所有storybook/*包将它们全部升级到指定版本自动处理 peer dependencies兼容 npm、yarn、pnpm。这些能力都能在源码中找到对应实现。命令入口定义在 bin/run.ts 的command(upgrade)其 action 调用 upgrade.ts 中的upgrade(options)主流程。完整流程如下第 1 步自动发现全部 Storybook 项目upgrade()首先调用getProjects(options)来自 util.ts。该函数用 glob 模式[**/.storybook, **/.rnstorybook]util.ts#L81从仓库根目录递归扫描所有 Storybook 配置目录并读取每个项目的main.js等配置与package.json中的当前版本。这正是 monorepo 场景下一条命令升级所有子项目的来源若多个 Storybook 项目共享package.json依赖命令会一次性全部升级并提示确认若各项目依赖相互独立则可以选择性地升级。官方文档 docs/releases/upgrading.mdx 还给出了大仓库收窄范围的方法——设置STORYBOOK_PROJECT_ROOT环境变量STORYBOOK_PROJECT_ROOT./packages/frontend storybooklatest upgrade需要注意的前提是务必从仓库根目录运行否则递归扫描无法覆盖全部项目。第 2 步Autoblocker 预检含大版本间隔拦截升级前先跑processAutoblockerResults其中最重要的拦截器是 block-major-version.ts 中定义的major-version-gap详见后文专节。第 3 步禁止降级校验upgrade.ts#L388-L399 中若非 canary 目标且目标版本低于当前版本直接抛出UpgradeStorybookToLowerVersionError若当前版本无法解析则抛出UpgradeStorybookUnknownCurrentVersionError。第 4 步改写全部 package.json 中的 Storybook 依赖upgradeStorybookDependenciesutil.ts#L509-L553是检测所有storybook/*包并全部升级的核心。它对每个项目关联的所有package.jsonmonorepo 中可能多个并行处理三组依赖const [upgradedDependencies, upgradedDevDependencies, upgradedPeerDependencies] await Promise.all([ generateUpgradeSpecs(packageJson.dependencies, config), generateUpgradeSpecs(packageJson.devDependencies, config), generateUpgradeSpecs(packageJson.peerDependencies, config), ]);也就是说dependencies、devDependencies和peerDependencies里的storybook/*包都会被统一改写为目标版本——这就是技能文档中自动处理 peer dependencies的出处也是绝不要用npm add手动装的原因之一见后文。当目标是精确的 prerelease/latest 版本时逻辑还会额外解析isSatelliteAddon的周边包并一并升级util.ts#L460-L486保证周边生态包与核心包版本匹配。在改写前upgrade()还会先对每个项目执行precheckStorybookPackageInstallupgrade.ts#L405-L419做 canary 包的最小发布年龄minimum-release-age预检避免安装到尚未构建完成的 canary 包。第 5 步安装与 monorepo 去重依赖声明改写后命令执行真正的安装installDependencies。源码中有一处细节npm 会额外传{ force: true }upgrade.ts#L468-L473注释指向 npm/cli#8059 问题以规避 lockfile 冲突。安装完成后若检测到项目处于 monorepo 且包管理器不是 yarn 1会交互式询问是否执行dedupe去重依赖--yes时自动执行并提示若运行 Storybook 出现问题可手动执行 dedupe 重试。第 6 步自动迁移Automigrations这是 upgrade 命令区别于单纯装包的关键价值。除非显式--skip-automigrations命令会调用runAutomigrationsautomigrate/multi-project.ts针对当前版本到目标版本之间的大版本破坏性变更执行自动迁移脚本。官方文档 docs/releases/upgrading.mdx 将其描述为升级流程的固有部分Run the relevant automigrations factoring in the breaking changes between your current version and the specified version。自动迁移还能在跨版本时延后配置新增的 addon例如 angular 到 angular-vite 迁移会引入addon-vitest/addon-a11y它们的 postinstall 钩子必须等依赖安装完成后才能解析upgrade()因此在安装之后调用configureDeferredAddons完成收尾配置upgrade.ts#L504-L530若失败会退化为提示你手动执行npx storybook add addon。第 7 步Doctor 健康检查与结果汇总升级与迁移完成后命令自动对每个项目运行多项目版 doctorrunMultiProjectDoctorupgrade.ts#L532-L545检查配置健康度随后logUpgradeResults将项目分为升级成功 / 迁移失败 / 无需迁移三类并打印同时输出每个已执行迁移项的说明链接与整体迁移指南指引。整个流程还支持SIGINT/SIGTERM中断处理与 telemetry 上报upgrade.ts#L359-L375这些行为与 docs/releases/upgrading.mdx 中Automatically run the doctor command to verify the upgrade的官方描述一致。全部 CLI 参数一览技能文档只展示了最简用法但 upgrade 命令实际支持一组完整的参数定义见 bin/run.ts#L163-L194 与UpgradeOptions类型upgrade.ts#L124-L138参数说明典型场景-y, --yes跳过所有交互确认CI 或脚本化执行--features list逗号分隔的实验特性开关通过 automigration 启用跨 10.5 升级时开启实验 flag-f, --force强制升级跳过 autoblockers明知有风险也要跨越版本拦截-n, --dry-run只检查不实际安装升级前预演-s, --skip-check跳过 postinstall 版本与 automigration 检查排障时减少干扰项--skip-automigrations完全不跑自动迁移只改包版本并安装手动处理迁移-c, --config-dir dir...指定 Storybook 配置目录可多个精确控制升级范围--package-manager type强制指定安装依赖所用包管理器检测到错误包管理器时其中两个参数的约束关系值得注意--features依赖 automigration 机制注入特性开关因此不能与--skip-automigrations组合源码在入口处直接报错upgrade.ts#L331-L336。为什么不能手动npm addStorybook 包技能文档用加粗强调的两条纪律绝不用npm add/yarn add/pnpm add手动安装 Storybook 包始终使用npx storybookversion upgrade保证全部包版本同步。其技术依据有二。其一Storybook 由数十个storybook/*包组成core、framework、addon、renderer 等手动逐个安装极易造成版本不一致——仓库甚至内置了checkVersionConsistency检查upgrade.ts#L84-L122它会通过npm ls解析已安装的storybook/*包按 semver 排序后列出与最新版本不一致的过期包并额外提示 6.0 起被废弃的包storybook/addon-notes、storybook/addon-info、storybook/addon-contexts、storybook/addon-options、storybook/addon-centered。其二如前文所述upgrade 命令会同时处理dependencies/devDependencies/peerDependencies三处声明以及 monorepo 下多个package.json手工操作几乎不可能覆盖同等范围。一次只升一个大版本铁律及其源码实现技能文档最重要的规则是ALWAYS upgrade only 1 major version at a time!示例路径为8.x → 9.x → 10.x → canary of 10明确禁止从 8.x 直接跳到 10.x。这条规则在源码中由 autoblocker 强制执行。block-major-version.ts 中的validateVersionTransition定义了三种判定// 降级目标版本低于当前版本 if (gt(currentVersion, targetVersion)) { return downgrade; } // 大版本间隔超过 1如 8.x 直接到 10.x const gap target.major - current.major; return gap 1 ? gap-too-large : ok;命中拦截时blocker 的 log 方法 会给出可操作的指引降级场景直接拒绝版本间隔过大场景则算出正确的中间步骤并打印命令——Your Storybook version (v8.x.x) is more than one major version behind the target release (v10.x.x). Please upgrade one major version at a time. You can upgrade to version 9 by running:npx storybook9 upgrade这与技能文档8.x → 9.x → 10.x的路径要求完全吻合工具不仅拦你还告诉你下一步该敲什么命令。从源码结构看该拦截对 major 为 0 的版本canary 形态做了豁免因此 canary 升级不会被误拦。若确有特殊原因需要跳过拦截可使用-f --force源码中 force 选项即描述为 force the upgrade, skipping autoblockers。官方文档还记录了一个历史例外从 6 直接升 8 是被允许的见 docs/releases/upgrading.mdx 的警告框。但除此之外跨越多个大版本必须逐级执行命令每一级都会重新运行对应的 automigration 与 doctor 检查这也是升级安全性的重要保障。升级前的准备与参考资料结合技能文档与源码一个可操作的升级检查清单是从仓库根目录执行让**/.storybook递归扫描覆盖所有子项目monorepo 可用STORYBOOK_PROJECT_ROOT收窄确认目标版本符合至多一个 major 间隔或准备好-f --forcecanary 目标需确认 PR 已构建完成canary 有 minimum-release-age 预检未构建完的包会被拒绝升级前浏览 MIGRATION.md 中对应版本的破坏性变更日志源码中多处日志与提示也以它为权威参考升级后阅读命令输出的 doctor 报告与 automigration 结果失败项目会指向 debug 日志。相关的深入材料均在仓库内可查官方升级文档 docs/releases/upgrading.mdxmonorepo 支持、实验特性开关行为、迁移指南 docs/releases/migration-guide.mdx、命令实现的单元测试 code/lib/cli-storybook/src/upgrade.test.ts以及降级拦截器的测试 code/lib/cli-storybook/src/autoblock/block-major-version.test.ts。小结storybook-upgrade技能看似只有一行命令但其背后是 upgrade 命令一整套工程化流程递归发现全部 Storybook 项目、三处依赖声明的一致性改写、canary 版本识别与预检、版本跨度 autoblocker、automigration 自动迁移、monorepo 依赖去重、doctor 健康检查。理解了这套流程你就能在 QA canary、复现 bug、跨版本迁移等场景下用一条npx storybookVERSION upgrade命令安全、同步、可追溯地完成整个仓库的 Storybook 升级。【免费下载链接】storybookStorybook is the industry standard workshop for building, documenting, and testing UI components in isolation项目地址: https://gitcode.com/GitHub_Trending/st/storybook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Storybook upgrade 命令实战：一次同步全部 @storybook/* 包，从技能脚本到源码级实现
Storybook upgrade 命令实战一次同步全部 storybook/* 包从技能脚本到源码级实现【免费下载链接】storybookStorybook is the industry standard workshop for building, documenting, and testing UI components in isolation项目地址: https://gitcode.com/GitHub_Trending/st/storybook本篇技术指南以 Storybook 仓库中的storybook-upgrade技能文档为核心完整讲解npx storybookVERSION upgrade的用法、canary 版本号规约并结合 upgrade.ts 等源码深入剖析 upgrade 命令的项目检测、依赖解析、自动迁移与健康检查流程。读完本文你将掌握在外部应用、复现项目或测试项目中把 Storybook 精确升级到指定版本release 或 canary的完整方案并理解一次只升一个大版本这条铁律在源码层面是如何被强制执行的。技能定位为什么需要升级到指定版本的专门工作流storybook-upgrade 技能实际内容位于 .agents/skills/storybook-upgrade/SKILL.md的原始用途写得非常明确它主要用于在本仓库之外验证 Storybook 的变更典型场景有二在下游应用中QA 某个 Storybook PR 的 canary 构建Upgrade a canary build from a Storybook PR在外部项目中复现或验证某个 bug。这两类场景与常见的把 Storybook 升到最新稳定版不同目标版本往往是一个随 PR 动态生成的 canary 版本号或某个历史 release例如回到 8.5.0 做对照测试。技能文档给出的标准命令只有一行npx storybookVERSION upgrade其中VERSION可以是三种形态技能文档分别给出了可复制的示例升级到 canary 版本npx storybook0.0.0-pr-33526-sha-a2e09fa2 upgrade升级到最新稳定版npx storybooklatest upgrade升级到指定 releasenpx storybook8.5.0 upgrade这种通过npx storybookversion指定 CLI 自身版本、再执行 upgrade的写法是关键技巧npx 会临时拉取该版本的storybook/cli由它按自己的版本逻辑去改写你项目里的全部 Storybook 依赖从而保证 CLI 版本与目标依赖版本一致。Canary 版本号解码0.0.0-pr-PR号-sha-短SHA技能文档示例中的0.0.0-pr-33526-sha-a2e09fa2不是随意编造的。配套的 canary 发布技能 说明了其生成规则GitHub Actions 会把 PR 构建并出版本号为0.0.0-pr-PR_NUMBER-sha-SHORT_SHA的包并打上canarytag其中PR_NUMBER是 PR 编号如33526SHORT_SHA是该 PR 最新 commit SHA 的前 8 位如a2e09fa2。也就是说只要知道 PR 号和最新 commit就可以自行拼出这个版本号。源码层面upgrade 命令对这类版本号有专门的识别逻辑。util.ts 中的isCanaryVersion函数判定以0.0.0开头的版本为 canary同时兼容portal:/workspace:前缀的本地/私有版本const isCanaryVersion (version: string): boolean version.startsWith(0.0.0) || version.startsWith(portal:) || version.startsWith(workspace:);这个判定直接影响后续行为——canary 升级会跳过降级校验见下文因为0.0.0-pr-*这种 pre-release 版本号在语义化版本比较中天然小于一切正式版本若不做特判会被误判为降级。upgrade 命令实际做了什么源码级流程拆解技能文档声称 upgrade 命令会做四件事检测项目中所有storybook/*包将它们全部升级到指定版本自动处理 peer dependencies兼容 npm、yarn、pnpm。这些能力都能在源码中找到对应实现。命令入口定义在 bin/run.ts 的command(upgrade)其 action 调用 upgrade.ts 中的upgrade(options)主流程。完整流程如下第 1 步自动发现全部 Storybook 项目upgrade()首先调用getProjects(options)来自 util.ts。该函数用 glob 模式[**/.storybook, **/.rnstorybook]util.ts#L81从仓库根目录递归扫描所有 Storybook 配置目录并读取每个项目的main.js等配置与package.json中的当前版本。这正是 monorepo 场景下一条命令升级所有子项目的来源若多个 Storybook 项目共享package.json依赖命令会一次性全部升级并提示确认若各项目依赖相互独立则可以选择性地升级。官方文档 docs/releases/upgrading.mdx 还给出了大仓库收窄范围的方法——设置STORYBOOK_PROJECT_ROOT环境变量STORYBOOK_PROJECT_ROOT./packages/frontend storybooklatest upgrade需要注意的前提是务必从仓库根目录运行否则递归扫描无法覆盖全部项目。第 2 步Autoblocker 预检含大版本间隔拦截升级前先跑processAutoblockerResults其中最重要的拦截器是 block-major-version.ts 中定义的major-version-gap详见后文专节。第 3 步禁止降级校验upgrade.ts#L388-L399 中若非 canary 目标且目标版本低于当前版本直接抛出UpgradeStorybookToLowerVersionError若当前版本无法解析则抛出UpgradeStorybookUnknownCurrentVersionError。第 4 步改写全部 package.json 中的 Storybook 依赖upgradeStorybookDependenciesutil.ts#L509-L553是检测所有storybook/*包并全部升级的核心。它对每个项目关联的所有package.jsonmonorepo 中可能多个并行处理三组依赖const [upgradedDependencies, upgradedDevDependencies, upgradedPeerDependencies] await Promise.all([ generateUpgradeSpecs(packageJson.dependencies, config), generateUpgradeSpecs(packageJson.devDependencies, config), generateUpgradeSpecs(packageJson.peerDependencies, config), ]);也就是说dependencies、devDependencies和peerDependencies里的storybook/*包都会被统一改写为目标版本——这就是技能文档中自动处理 peer dependencies的出处也是绝不要用npm add手动装的原因之一见后文。当目标是精确的 prerelease/latest 版本时逻辑还会额外解析isSatelliteAddon的周边包并一并升级util.ts#L460-L486保证周边生态包与核心包版本匹配。在改写前upgrade()还会先对每个项目执行precheckStorybookPackageInstallupgrade.ts#L405-L419做 canary 包的最小发布年龄minimum-release-age预检避免安装到尚未构建完成的 canary 包。第 5 步安装与 monorepo 去重依赖声明改写后命令执行真正的安装installDependencies。源码中有一处细节npm 会额外传{ force: true }upgrade.ts#L468-L473注释指向 npm/cli#8059 问题以规避 lockfile 冲突。安装完成后若检测到项目处于 monorepo 且包管理器不是 yarn 1会交互式询问是否执行dedupe去重依赖--yes时自动执行并提示若运行 Storybook 出现问题可手动执行 dedupe 重试。第 6 步自动迁移Automigrations这是 upgrade 命令区别于单纯装包的关键价值。除非显式--skip-automigrations命令会调用runAutomigrationsautomigrate/multi-project.ts针对当前版本到目标版本之间的大版本破坏性变更执行自动迁移脚本。官方文档 docs/releases/upgrading.mdx 将其描述为升级流程的固有部分Run the relevant automigrations factoring in the breaking changes between your current version and the specified version。自动迁移还能在跨版本时延后配置新增的 addon例如 angular 到 angular-vite 迁移会引入addon-vitest/addon-a11y它们的 postinstall 钩子必须等依赖安装完成后才能解析upgrade()因此在安装之后调用configureDeferredAddons完成收尾配置upgrade.ts#L504-L530若失败会退化为提示你手动执行npx storybook add addon。第 7 步Doctor 健康检查与结果汇总升级与迁移完成后命令自动对每个项目运行多项目版 doctorrunMultiProjectDoctorupgrade.ts#L532-L545检查配置健康度随后logUpgradeResults将项目分为升级成功 / 迁移失败 / 无需迁移三类并打印同时输出每个已执行迁移项的说明链接与整体迁移指南指引。整个流程还支持SIGINT/SIGTERM中断处理与 telemetry 上报upgrade.ts#L359-L375这些行为与 docs/releases/upgrading.mdx 中Automatically run the doctor command to verify the upgrade的官方描述一致。全部 CLI 参数一览技能文档只展示了最简用法但 upgrade 命令实际支持一组完整的参数定义见 bin/run.ts#L163-L194 与UpgradeOptions类型upgrade.ts#L124-L138参数说明典型场景-y, --yes跳过所有交互确认CI 或脚本化执行--features list逗号分隔的实验特性开关通过 automigration 启用跨 10.5 升级时开启实验 flag-f, --force强制升级跳过 autoblockers明知有风险也要跨越版本拦截-n, --dry-run只检查不实际安装升级前预演-s, --skip-check跳过 postinstall 版本与 automigration 检查排障时减少干扰项--skip-automigrations完全不跑自动迁移只改包版本并安装手动处理迁移-c, --config-dir dir...指定 Storybook 配置目录可多个精确控制升级范围--package-manager type强制指定安装依赖所用包管理器检测到错误包管理器时其中两个参数的约束关系值得注意--features依赖 automigration 机制注入特性开关因此不能与--skip-automigrations组合源码在入口处直接报错upgrade.ts#L331-L336。为什么不能手动npm addStorybook 包技能文档用加粗强调的两条纪律绝不用npm add/yarn add/pnpm add手动安装 Storybook 包始终使用npx storybookversion upgrade保证全部包版本同步。其技术依据有二。其一Storybook 由数十个storybook/*包组成core、framework、addon、renderer 等手动逐个安装极易造成版本不一致——仓库甚至内置了checkVersionConsistency检查upgrade.ts#L84-L122它会通过npm ls解析已安装的storybook/*包按 semver 排序后列出与最新版本不一致的过期包并额外提示 6.0 起被废弃的包storybook/addon-notes、storybook/addon-info、storybook/addon-contexts、storybook/addon-options、storybook/addon-centered。其二如前文所述upgrade 命令会同时处理dependencies/devDependencies/peerDependencies三处声明以及 monorepo 下多个package.json手工操作几乎不可能覆盖同等范围。一次只升一个大版本铁律及其源码实现技能文档最重要的规则是ALWAYS upgrade only 1 major version at a time!示例路径为8.x → 9.x → 10.x → canary of 10明确禁止从 8.x 直接跳到 10.x。这条规则在源码中由 autoblocker 强制执行。block-major-version.ts 中的validateVersionTransition定义了三种判定// 降级目标版本低于当前版本 if (gt(currentVersion, targetVersion)) { return downgrade; } // 大版本间隔超过 1如 8.x 直接到 10.x const gap target.major - current.major; return gap 1 ? gap-too-large : ok;命中拦截时blocker 的 log 方法 会给出可操作的指引降级场景直接拒绝版本间隔过大场景则算出正确的中间步骤并打印命令——Your Storybook version (v8.x.x) is more than one major version behind the target release (v10.x.x). Please upgrade one major version at a time. You can upgrade to version 9 by running:npx storybook9 upgrade这与技能文档8.x → 9.x → 10.x的路径要求完全吻合工具不仅拦你还告诉你下一步该敲什么命令。从源码结构看该拦截对 major 为 0 的版本canary 形态做了豁免因此 canary 升级不会被误拦。若确有特殊原因需要跳过拦截可使用-f --force源码中 force 选项即描述为 force the upgrade, skipping autoblockers。官方文档还记录了一个历史例外从 6 直接升 8 是被允许的见 docs/releases/upgrading.mdx 的警告框。但除此之外跨越多个大版本必须逐级执行命令每一级都会重新运行对应的 automigration 与 doctor 检查这也是升级安全性的重要保障。升级前的准备与参考资料结合技能文档与源码一个可操作的升级检查清单是从仓库根目录执行让**/.storybook递归扫描覆盖所有子项目monorepo 可用STORYBOOK_PROJECT_ROOT收窄确认目标版本符合至多一个 major 间隔或准备好-f --forcecanary 目标需确认 PR 已构建完成canary 有 minimum-release-age 预检未构建完的包会被拒绝升级前浏览 MIGRATION.md 中对应版本的破坏性变更日志源码中多处日志与提示也以它为权威参考升级后阅读命令输出的 doctor 报告与 automigration 结果失败项目会指向 debug 日志。相关的深入材料均在仓库内可查官方升级文档 docs/releases/upgrading.mdxmonorepo 支持、实验特性开关行为、迁移指南 docs/releases/migration-guide.mdx、命令实现的单元测试 code/lib/cli-storybook/src/upgrade.test.ts以及降级拦截器的测试 code/lib/cli-storybook/src/autoblock/block-major-version.test.ts。小结storybook-upgrade技能看似只有一行命令但其背后是 upgrade 命令一整套工程化流程递归发现全部 Storybook 项目、三处依赖声明的一致性改写、canary 版本识别与预检、版本跨度 autoblocker、automigration 自动迁移、monorepo 依赖去重、doctor 健康检查。理解了这套流程你就能在 QA canary、复现 bug、跨版本迁移等场景下用一条npx storybookVERSION upgrade命令安全、同步、可追溯地完成整个仓库的 Storybook 升级。【免费下载链接】storybookStorybook is the industry standard workshop for building, documenting, and testing UI components in isolation项目地址: https://gitcode.com/GitHub_Trending/st/storybook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考