Effect TypeScript Monorepo 依赖维护实战指南把升级当作同步任务而非 Lockfile 刷新【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect导读本指南基于 dependency-maintenance SKILL 展开讲解 Effect TypeScript 单仓库monorepo中依赖升级的正确姿势将每一次升级视为一次需要跨清单、工作流、测试配置、补丁与原生构建策略的同步任务而不是简单的pnpm install刷新。读完本文你将掌握发现—分支选择—同步点更新—安装验证—最窄测试—changeset 路由的完整操作链路并理解该仓库中pnpm-workspace.yaml、package.json、CI setup action 等真实配置背后的设计意图。一、核心认知升级是同步任务不是 lockfile 刷新SKILL 开篇就给出了本仓库依赖维护的第一原则Treat an upgrade as a synchronization task, not a lockfile refresh. Derive versions, commands, and compatibility points from the current repository.把升级当作同步任务而不是 lockfile 刷新。从当前仓库推导版本、命令与兼容点。这句话有两层含义一个依赖升级会牵动多个表面除了拥有它的package.json还可能有pnpm-workspace.yaml、CI workflow、setup action、测试配置、兼容性文档、补丁文件patch等只更新清单而不更新这些表面仓库内部就会产生隐性不一致。版本号、命令与兼容约束必须从仓库现状推导不要凭记忆或外部假设写版本而要读取仓库中所有出现该依赖的位置SKILL.md。为什么这不是一个锁文件刷新锁文件pnpm-lock.yaml只是安装结果的记录。如果清单、workspace 设置、patch 哈希、allowBuilds 策略、CI 工具版本没有同步更新锁文件即使能生成也掩盖了构建面与发布面的不一致。SKILL 强调成功的安装本身并不能完成审查A successful install alone does not complete this review正是针对这一陷阱。二、Discover发现先盘点再动手SKILL 规定的发现阶段包含五个步骤其目标是把仓库中每一个与该依赖相关的匹配点都记录在案然后才允许进入编辑。2.1 读取受影响的配置文件面第一步是通读下列文件建立同步面清单受影响的 manifestspackage.json及各 workspace 包清单构建/维护脚本本仓库根目录 package.json 中定义了build、check、test、codegen、lint、typeperf、runtimeperf、changeset-version等命令pnpm-workspace.yamlworkspace 声明、verifyDepsBeforeRun、allowBuilds、patchedDependenciessetup actions 与 workflows见 .github/actions/setup/action.yaml测试配置vitest.config.ts、vitest.docs.ts等兼容性文档本仓库的 MIGRATION.md、migration/目录等2.2 搜索依赖的每一个版本痕迹第二步要求搜索该依赖及它的每个当前版本、范围、运行时输入、镜像、引擎约束、补丁与兼容性声明。例如要升级changesets/cli就需要同时命中根 package.json 中的devDependencies、.changeset目录的使用方式、以及 pnpm-workspace.yaml 中对该补丁包的patchedDependencies记录。2.3 将每个匹配分类第三步把每一处匹配归类为以下五类之一分类含义仓库中的典型位置Development version开发/测试实际安装的版本根与各包的devDependenciesTested version被 CI 与测试真正验证过的版本.github/actions/setup/action.yaml 中的 Node 版本、package.json的devDependenciesPeer range面向消费者的兼容范围各包的peerDependenciesEngine minimum运行时引擎下限package.json的engines字段Advertised minimum文档/README 宣称的最低支持各包 README、MIGRATION.md关键点在于这五类值通常各不相同且不允许互相串味。一个包可以在仓库内以 TypeScript 7 开发测试同时对消费者声明较低的 peer 范围。2.4 新增/移动清单条目前先读 manifest-rolesSKILL 明确要求When adding or moving a manifest entry, read manifest-roles.md before selecting its role.新增或移动清单条目时先读 manifest-roles 再选择其角色。manifest-roles.md 定义了六种清单角色及其完成检查角色适用场景完成检查dependencies发布后的运行时代码需要自己的安装副本打包后的消费者能拿到它且不会出现未声明的包peerDependencies消费者提供兼容的共享包或公共契约与消费者的副本集成范围声明支持的消费者版本本地构建/测试需要安装副本时额外添加 dev 条目devDependencies仅仓库构建、测试、类型检查、基准或代码生成需要发布后的运行时代码与声明文件不要求消费者安装它optionalDependencies运行时特性可容忍缺失且安装失败不得阻塞基础包聚焦测试覆盖存在与缺失两种行为peerDependenciesMeta中的可选 peer消费者提供的集成是真正可选的peer 仍在peerDependencies中代码仅在选中时才 require 它补充说明本仓库的 package-development/dependencies.md 还给出了一条配套惯例——workspace 包使用workspace:^除非相邻包确立了不同策略当本地构建或测试需要已安装的 peer 时将 peer 以仓库测试版本加入devDependencies同时 peer 范围仍基于受支持的消费者版本。2.5 选择分支与验证矩阵最后一步是决定本次改动走package-local 分支还是coordinated 分支并确定其验证矩阵。发现阶段完成的标准是every match and affected validation surface is accounted for每个匹配与受影响的验证面都被登记在案。三、Package-local 分支单包单依赖的最小改动3.1 适用前提只有满足全部下列条件才允许使用 package-local 分支只动一个 workspace 包中的一个依赖运行时、编译器、包管理器、镜像、补丁、原生构建native-build与共享工具策略全部不变。也就是说凡是策略面有变化就不属于本地分支的范畴。3.2 做法与完成标准只更新拥有该依赖的清单owning manifest让 peer 兼容性独立于本次测试的开发版本keep peer compatibility independent from the development version tested here一旦出现任何协调面coordinated surface立即切换分支。完成标准清单与 lockfile 一致、聚焦检查通过、且每一条搜索结果要么有意不变、要么属于包本地改动。四、Coordinated 分支多面同步升级当升级牵动共享依赖、工具链、运行时或补丁时必须走 coordinated 分支。SKILL 要求先读 coordinated-upgrades.md选择所有适用行在安装前更新全部列出的同步点然后返回主流程完成矩阵与 lockfile 审查。该文档给出了七类升级及其同步面与验证来源变更类型需要同步的表面验证来源共享依赖或测试/构建工具拥有它的 manifests、peer/development 配对、配置、该工具生成的产物根/包脚本与受影响的 Vitest 项目pnpm根packageManager、workspace 设置、setup/cache 假设、workflows、lockfile 格式当前 install、lint、check、build 与聚焦测试脚本Node、Deno 或 Bunsetup 输入、workflow 任务、engines、运行时元数据、兼容性文档、运行时配置当前运行时 workflow 任务与测试配置TypeScript 支持或编译器编译器/工具依赖、test-types目标、CI 目标、工具 peer 范围、兼容性文档、typetests目标 typetests测量路径用 typeperf 协议原生包或安装策略拥有它的 manifests 与pnpm-workspace.yaml#allowBuilds全新安装 聚焦包构建与测试被补丁的依赖manifest/范围、patchedDependencies、补丁文件、lockfile 补丁哈希全新安装 需要该补丁的行为容器镜像或 Testcontainers 包workflow 预拉取、镜像调用点、manifests、集成项目名当前集成 workflow 与 Vitest 配置4.1 补丁依赖的特殊处理对被补丁的依赖coordinated-upgrades 文档给出了三条细则可行时不带补丁测试新版本也许上游已修复若补丁不再必要删除过时的注册条目与补丁文件否则用当前 pnpm workflow 刷新补丁并同时验证两件事补丁能应用且原始被打补丁的行为仍然需要它。本仓库正好有一个活样本pnpm-workspace.yaml 中声明了patchedDependencies: changesets/get-github-info1.0.1: patches/changesets__get-github-info1.0.1.patch而根 package.json 中changesets/changelog-github固定在1.0.1。升级这类依赖时lockfile 中 patch 哈希的变化integrity/patch hash就是必须人工审查的关键点之一。4.2 性能测量路径的约束SKILL 的配套文档强调When an upgraded component lies on a measured path, use the repositorys runtimeperf or typeperf comparison protocol rather than inventing a benchmark.当升级组件位于被测量的路径上时使用仓库的 runtimeperf 或 typeperf 对比协议而不是自创基准。本仓库在 packages/effect/runtimeperf 与 packages/effect/typeperf 中内置了两套对比工具根 package.json 暴露了typeperf、typeperf-compare、runtimeperf、runtimeperf-compare四个命令。升级 TypeScript 编译器或影响热路径的依赖时应运行pnpm typeperf-compare/pnpm runtimeperf-compare与基线对比而不是临时写一个一次性基准。五、Install and finish安装、审查与收尾5.1 运行根 pnpm install在所有选定编辑完成后从仓库根目录运行pnpm install本仓库根 package.json 声明packageManager: pnpm11.20.0配套的 CI setup 在 .github/actions/setup/action.yaml 中通过pnpm/action-setup安装对应版本。5.2 审查 lockfile 语义差异SKILL 要求安装后检查语义层的 lockfile 差异而不是只看是否成功。审查点清单检查项含义specifiers清单声明范围是否按预期进入 lockfileresolutions解析到的具体版本是否与预期一致duplicate transitives是否出现非预期的传递依赖重复同一包多个版本peer changespeer 依赖解析是否变化integrity完整性哈希是否符合预期patch hashes补丁哈希是否与patchedDependencies一致lifecycle scripts安装脚本执行面是否变化allowBuildseffectspnpm-workspace.yaml 的allowBuilds策略是否被绕过本仓库的pnpm-workspace.yaml提供了两个与本流程强相关的策略verifyDepsBeforeRun: error # 运行脚本前校验依赖避免清单改了但没安装的漂移 allowBuilds: # 白名单式地关闭原生构建脚本 core-js: false dprint: false esbuild: false sharp: false ...verifyDepsBeforeRun: error意味着一旦清单与 lockfile 脱节后续pnpm test、pnpm build等脚本会直接报错——这正是 SKILL先同步再安装流程的工程保障而allowBuilds则是原生包/安装策略升级coordinated-upgrades 表格第五行的直接落点升级带原生构建的依赖时若其安装脚本不再可信或不再必要应在此白名单中登记为false。5.3 运行最窄验证SKILL 要求运行能覆盖每个选定矩阵行的最窄正确性与性能检查。本仓库 .agents/AGENTS.md 给出了与 SKILL 配套的验证矩阵变更类型验证命令代码变更pnpm lint-fix、定向pnpm test --run test_file.ts、pnpm check仅测试变更同上类型级/API 类型变更定向pnpm test-types filename源类型变更时加pnpm checkJSDoc 文本/类别/链接变更pnpm jsdocs --check、pnpm lintJSDoc 示例变更pnpm jsdocs --check、pnpm lint、根pnpm doctest --run files仅文档变更pnpm lint-fix除非示例或代码变更否则无需测试两条值得强调的仓库约束绝不裸跑pnpm test或pnpm doctest——两者默认以 watch 模式启动全量套件必须带--run与具体文件见 .agents/AGENTS.md依赖升级如果改变类型面应使用定向pnpm test-types filename根脚本test-types使用tstyche --target 5.9涉及测量路径时用 typeperf/runtimeperf 对比协议。5.4 changeset 路由在实现与聚焦验证之后应用根 changeset 路由Apply the root changeset routing after implementation and focused validation。本仓库的变更记录集中在.changeset目录由changeset-version、changeset-publish脚本驱动见 package.json。顺序本身是流程的一部分先改、先验证最后再登记变更集避免为未经验证的改动提前发布声明。六、完成标准如何判定任务真正结束SKILL 给出了四条可操作的完成判据重复仓库搜索不再发现未分类的同步点——每个出现该依赖的位置都被明确归类为有意不变或已同步manifest 角色与兼容范围是有意选择的——每处条目都能在 manifest-roles.md 中找到一条正当理由lockfile 没有无法解释的扰动churn——所有差异都能对应到上面的语义审查项每个选中的检查通过或明确报告为不可运行——不得悄悄跳过。七、仓库配套维护者的操作手册体系本仓库把依赖维护的能力沉淀为一套可复用的 Agent 技能skills分布在 .agents/skills 目录下与本主题直接相关的是dependency-maintenance/SKILL.md——本文的主体来源定义发现、分支、安装与收尾全流程dependency-maintenance/coordinated-upgrades.md——七类协调升级的同步面与验证来源表dependency-maintenance/manifest-roles.md——六种清单角色的选择依据与完成检查package-development/dependencies.md——包级依赖角色分类与 workspace/peer 策略ci-maintenance/SKILL.md——与之相邻的 CI 维护技能覆盖 workflow 信任边界与 setup 复用升级 pnpm/Node 时二者常常同时被触发。这些技能文件与仓库真实配置package.json、pnpm-workspace.yaml、.github/actions/setup/action.yaml、.agents/AGENTS.md互为印证技能文档描述应该怎么做配置文件固化这个仓库实际怎么做。例如升级 Node 版本时技能要求同步 setup 输入、workflow 任务与 engines而仓库中 .github/actions/setup/action.yaml 的node-version: 26.4.0、可选的deno-version/bun-version输入正是这一要求的具体实现——三处setup 输入、CI 任务、清单引擎约束必须保持一致才能通过重复搜索无未分类同步点的完成检查。结语Effect TypeScript 单仓库的依赖维护本质上是一套可审计的同步纪律发现阶段把仓库当作事实来源逐面盘点分支选择决定改动半径coordinated 矩阵规定同步点安装后的语义审查拦截隐形漂移最窄验证与 changeset 路由则保证改动既可证明又可按版本发布。对维护者而言掌握 SKILL.md 及其配套文档就等于拿到了一份把升级依赖从琐碎操作提升为受控工程流程的可执行清单。【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Effect TypeScript Monorepo 依赖维护实战指南：把升级当作同步任务而非 Lockfile 刷新
Effect TypeScript Monorepo 依赖维护实战指南把升级当作同步任务而非 Lockfile 刷新【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect导读本指南基于 dependency-maintenance SKILL 展开讲解 Effect TypeScript 单仓库monorepo中依赖升级的正确姿势将每一次升级视为一次需要跨清单、工作流、测试配置、补丁与原生构建策略的同步任务而不是简单的pnpm install刷新。读完本文你将掌握发现—分支选择—同步点更新—安装验证—最窄测试—changeset 路由的完整操作链路并理解该仓库中pnpm-workspace.yaml、package.json、CI setup action 等真实配置背后的设计意图。一、核心认知升级是同步任务不是 lockfile 刷新SKILL 开篇就给出了本仓库依赖维护的第一原则Treat an upgrade as a synchronization task, not a lockfile refresh. Derive versions, commands, and compatibility points from the current repository.把升级当作同步任务而不是 lockfile 刷新。从当前仓库推导版本、命令与兼容点。这句话有两层含义一个依赖升级会牵动多个表面除了拥有它的package.json还可能有pnpm-workspace.yaml、CI workflow、setup action、测试配置、兼容性文档、补丁文件patch等只更新清单而不更新这些表面仓库内部就会产生隐性不一致。版本号、命令与兼容约束必须从仓库现状推导不要凭记忆或外部假设写版本而要读取仓库中所有出现该依赖的位置SKILL.md。为什么这不是一个锁文件刷新锁文件pnpm-lock.yaml只是安装结果的记录。如果清单、workspace 设置、patch 哈希、allowBuilds 策略、CI 工具版本没有同步更新锁文件即使能生成也掩盖了构建面与发布面的不一致。SKILL 强调成功的安装本身并不能完成审查A successful install alone does not complete this review正是针对这一陷阱。二、Discover发现先盘点再动手SKILL 规定的发现阶段包含五个步骤其目标是把仓库中每一个与该依赖相关的匹配点都记录在案然后才允许进入编辑。2.1 读取受影响的配置文件面第一步是通读下列文件建立同步面清单受影响的 manifestspackage.json及各 workspace 包清单构建/维护脚本本仓库根目录 package.json 中定义了build、check、test、codegen、lint、typeperf、runtimeperf、changeset-version等命令pnpm-workspace.yamlworkspace 声明、verifyDepsBeforeRun、allowBuilds、patchedDependenciessetup actions 与 workflows见 .github/actions/setup/action.yaml测试配置vitest.config.ts、vitest.docs.ts等兼容性文档本仓库的 MIGRATION.md、migration/目录等2.2 搜索依赖的每一个版本痕迹第二步要求搜索该依赖及它的每个当前版本、范围、运行时输入、镜像、引擎约束、补丁与兼容性声明。例如要升级changesets/cli就需要同时命中根 package.json 中的devDependencies、.changeset目录的使用方式、以及 pnpm-workspace.yaml 中对该补丁包的patchedDependencies记录。2.3 将每个匹配分类第三步把每一处匹配归类为以下五类之一分类含义仓库中的典型位置Development version开发/测试实际安装的版本根与各包的devDependenciesTested version被 CI 与测试真正验证过的版本.github/actions/setup/action.yaml 中的 Node 版本、package.json的devDependenciesPeer range面向消费者的兼容范围各包的peerDependenciesEngine minimum运行时引擎下限package.json的engines字段Advertised minimum文档/README 宣称的最低支持各包 README、MIGRATION.md关键点在于这五类值通常各不相同且不允许互相串味。一个包可以在仓库内以 TypeScript 7 开发测试同时对消费者声明较低的 peer 范围。2.4 新增/移动清单条目前先读 manifest-rolesSKILL 明确要求When adding or moving a manifest entry, read manifest-roles.md before selecting its role.新增或移动清单条目时先读 manifest-roles 再选择其角色。manifest-roles.md 定义了六种清单角色及其完成检查角色适用场景完成检查dependencies发布后的运行时代码需要自己的安装副本打包后的消费者能拿到它且不会出现未声明的包peerDependencies消费者提供兼容的共享包或公共契约与消费者的副本集成范围声明支持的消费者版本本地构建/测试需要安装副本时额外添加 dev 条目devDependencies仅仓库构建、测试、类型检查、基准或代码生成需要发布后的运行时代码与声明文件不要求消费者安装它optionalDependencies运行时特性可容忍缺失且安装失败不得阻塞基础包聚焦测试覆盖存在与缺失两种行为peerDependenciesMeta中的可选 peer消费者提供的集成是真正可选的peer 仍在peerDependencies中代码仅在选中时才 require 它补充说明本仓库的 package-development/dependencies.md 还给出了一条配套惯例——workspace 包使用workspace:^除非相邻包确立了不同策略当本地构建或测试需要已安装的 peer 时将 peer 以仓库测试版本加入devDependencies同时 peer 范围仍基于受支持的消费者版本。2.5 选择分支与验证矩阵最后一步是决定本次改动走package-local 分支还是coordinated 分支并确定其验证矩阵。发现阶段完成的标准是every match and affected validation surface is accounted for每个匹配与受影响的验证面都被登记在案。三、Package-local 分支单包单依赖的最小改动3.1 适用前提只有满足全部下列条件才允许使用 package-local 分支只动一个 workspace 包中的一个依赖运行时、编译器、包管理器、镜像、补丁、原生构建native-build与共享工具策略全部不变。也就是说凡是策略面有变化就不属于本地分支的范畴。3.2 做法与完成标准只更新拥有该依赖的清单owning manifest让 peer 兼容性独立于本次测试的开发版本keep peer compatibility independent from the development version tested here一旦出现任何协调面coordinated surface立即切换分支。完成标准清单与 lockfile 一致、聚焦检查通过、且每一条搜索结果要么有意不变、要么属于包本地改动。四、Coordinated 分支多面同步升级当升级牵动共享依赖、工具链、运行时或补丁时必须走 coordinated 分支。SKILL 要求先读 coordinated-upgrades.md选择所有适用行在安装前更新全部列出的同步点然后返回主流程完成矩阵与 lockfile 审查。该文档给出了七类升级及其同步面与验证来源变更类型需要同步的表面验证来源共享依赖或测试/构建工具拥有它的 manifests、peer/development 配对、配置、该工具生成的产物根/包脚本与受影响的 Vitest 项目pnpm根packageManager、workspace 设置、setup/cache 假设、workflows、lockfile 格式当前 install、lint、check、build 与聚焦测试脚本Node、Deno 或 Bunsetup 输入、workflow 任务、engines、运行时元数据、兼容性文档、运行时配置当前运行时 workflow 任务与测试配置TypeScript 支持或编译器编译器/工具依赖、test-types目标、CI 目标、工具 peer 范围、兼容性文档、typetests目标 typetests测量路径用 typeperf 协议原生包或安装策略拥有它的 manifests 与pnpm-workspace.yaml#allowBuilds全新安装 聚焦包构建与测试被补丁的依赖manifest/范围、patchedDependencies、补丁文件、lockfile 补丁哈希全新安装 需要该补丁的行为容器镜像或 Testcontainers 包workflow 预拉取、镜像调用点、manifests、集成项目名当前集成 workflow 与 Vitest 配置4.1 补丁依赖的特殊处理对被补丁的依赖coordinated-upgrades 文档给出了三条细则可行时不带补丁测试新版本也许上游已修复若补丁不再必要删除过时的注册条目与补丁文件否则用当前 pnpm workflow 刷新补丁并同时验证两件事补丁能应用且原始被打补丁的行为仍然需要它。本仓库正好有一个活样本pnpm-workspace.yaml 中声明了patchedDependencies: changesets/get-github-info1.0.1: patches/changesets__get-github-info1.0.1.patch而根 package.json 中changesets/changelog-github固定在1.0.1。升级这类依赖时lockfile 中 patch 哈希的变化integrity/patch hash就是必须人工审查的关键点之一。4.2 性能测量路径的约束SKILL 的配套文档强调When an upgraded component lies on a measured path, use the repositorys runtimeperf or typeperf comparison protocol rather than inventing a benchmark.当升级组件位于被测量的路径上时使用仓库的 runtimeperf 或 typeperf 对比协议而不是自创基准。本仓库在 packages/effect/runtimeperf 与 packages/effect/typeperf 中内置了两套对比工具根 package.json 暴露了typeperf、typeperf-compare、runtimeperf、runtimeperf-compare四个命令。升级 TypeScript 编译器或影响热路径的依赖时应运行pnpm typeperf-compare/pnpm runtimeperf-compare与基线对比而不是临时写一个一次性基准。五、Install and finish安装、审查与收尾5.1 运行根 pnpm install在所有选定编辑完成后从仓库根目录运行pnpm install本仓库根 package.json 声明packageManager: pnpm11.20.0配套的 CI setup 在 .github/actions/setup/action.yaml 中通过pnpm/action-setup安装对应版本。5.2 审查 lockfile 语义差异SKILL 要求安装后检查语义层的 lockfile 差异而不是只看是否成功。审查点清单检查项含义specifiers清单声明范围是否按预期进入 lockfileresolutions解析到的具体版本是否与预期一致duplicate transitives是否出现非预期的传递依赖重复同一包多个版本peer changespeer 依赖解析是否变化integrity完整性哈希是否符合预期patch hashes补丁哈希是否与patchedDependencies一致lifecycle scripts安装脚本执行面是否变化allowBuildseffectspnpm-workspace.yaml 的allowBuilds策略是否被绕过本仓库的pnpm-workspace.yaml提供了两个与本流程强相关的策略verifyDepsBeforeRun: error # 运行脚本前校验依赖避免清单改了但没安装的漂移 allowBuilds: # 白名单式地关闭原生构建脚本 core-js: false dprint: false esbuild: false sharp: false ...verifyDepsBeforeRun: error意味着一旦清单与 lockfile 脱节后续pnpm test、pnpm build等脚本会直接报错——这正是 SKILL先同步再安装流程的工程保障而allowBuilds则是原生包/安装策略升级coordinated-upgrades 表格第五行的直接落点升级带原生构建的依赖时若其安装脚本不再可信或不再必要应在此白名单中登记为false。5.3 运行最窄验证SKILL 要求运行能覆盖每个选定矩阵行的最窄正确性与性能检查。本仓库 .agents/AGENTS.md 给出了与 SKILL 配套的验证矩阵变更类型验证命令代码变更pnpm lint-fix、定向pnpm test --run test_file.ts、pnpm check仅测试变更同上类型级/API 类型变更定向pnpm test-types filename源类型变更时加pnpm checkJSDoc 文本/类别/链接变更pnpm jsdocs --check、pnpm lintJSDoc 示例变更pnpm jsdocs --check、pnpm lint、根pnpm doctest --run files仅文档变更pnpm lint-fix除非示例或代码变更否则无需测试两条值得强调的仓库约束绝不裸跑pnpm test或pnpm doctest——两者默认以 watch 模式启动全量套件必须带--run与具体文件见 .agents/AGENTS.md依赖升级如果改变类型面应使用定向pnpm test-types filename根脚本test-types使用tstyche --target 5.9涉及测量路径时用 typeperf/runtimeperf 对比协议。5.4 changeset 路由在实现与聚焦验证之后应用根 changeset 路由Apply the root changeset routing after implementation and focused validation。本仓库的变更记录集中在.changeset目录由changeset-version、changeset-publish脚本驱动见 package.json。顺序本身是流程的一部分先改、先验证最后再登记变更集避免为未经验证的改动提前发布声明。六、完成标准如何判定任务真正结束SKILL 给出了四条可操作的完成判据重复仓库搜索不再发现未分类的同步点——每个出现该依赖的位置都被明确归类为有意不变或已同步manifest 角色与兼容范围是有意选择的——每处条目都能在 manifest-roles.md 中找到一条正当理由lockfile 没有无法解释的扰动churn——所有差异都能对应到上面的语义审查项每个选中的检查通过或明确报告为不可运行——不得悄悄跳过。七、仓库配套维护者的操作手册体系本仓库把依赖维护的能力沉淀为一套可复用的 Agent 技能skills分布在 .agents/skills 目录下与本主题直接相关的是dependency-maintenance/SKILL.md——本文的主体来源定义发现、分支、安装与收尾全流程dependency-maintenance/coordinated-upgrades.md——七类协调升级的同步面与验证来源表dependency-maintenance/manifest-roles.md——六种清单角色的选择依据与完成检查package-development/dependencies.md——包级依赖角色分类与 workspace/peer 策略ci-maintenance/SKILL.md——与之相邻的 CI 维护技能覆盖 workflow 信任边界与 setup 复用升级 pnpm/Node 时二者常常同时被触发。这些技能文件与仓库真实配置package.json、pnpm-workspace.yaml、.github/actions/setup/action.yaml、.agents/AGENTS.md互为印证技能文档描述应该怎么做配置文件固化这个仓库实际怎么做。例如升级 Node 版本时技能要求同步 setup 输入、workflow 任务与 engines而仓库中 .github/actions/setup/action.yaml 的node-version: 26.4.0、可选的deno-version/bun-version输入正是这一要求的具体实现——三处setup 输入、CI 任务、清单引擎约束必须保持一致才能通过重复搜索无未分类同步点的完成检查。结语Effect TypeScript 单仓库的依赖维护本质上是一套可审计的同步纪律发现阶段把仓库当作事实来源逐面盘点分支选择决定改动半径coordinated 矩阵规定同步点安装后的语义审查拦截隐形漂移最窄验证与 changeset 路由则保证改动既可证明又可按版本发布。对维护者而言掌握 SKILL.md 及其配套文档就等于拿到了一份把升级依赖从琐碎操作提升为受控工程流程的可执行清单。【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考