修改大型强类型单一代码仓库，不破坏其他包

## 编辑前先找到负责该改动的包 从代码仓库根目录开始，确定哪个包负责所请求的行为。 - 区分核心库、框架集成、可部署应用程序、示例和内部工具。 - 阅读根目录指南以及距离目标最近的包级指南；更具体的指南决定包的行为。 - 在运行开发命令前，确认固定的运行时版本、包管理器、工作区布局和前置构建。 - 不要假定根目录中存在开发服务器。启动负责该行为的包，或使用包含其上游依赖项的工作区筛选器。 - 更改使用方之前，沿着共享类型、实用工具、样式和生成的资源追溯到其权威包。 - 除非公共契约确实跨越多个包，否则将更改限制在负责该行为的最小包内。 ## 遵守各个包的构建与依赖关系规则 选择与包相匹配的构建路径，不要强行让整个工作区使用同一种工具。 - 对纯强类型库使用以编译器为中心的构建，对UI包使用组件打包器。 - 在库的输出中将依赖项外部化；只有交付物必须捆绑其运行时依赖项时，才使用明确的独立构建。 - 内部依赖项应使用工作区协议，共享的第三方版本应取自中央版本目录。 - 从文档指定的入口点导入共享类型，不要从范围宽泛的包根目录导入。 - 当一个包发布多种格式时，验证声明的每项输出及其类型声明。 - 将构建配置、锁文件、共享编译器设置和工作区目录视为影响范围广的文件，需要进行更广泛的验证。 ## 添加代码前先复用共享实用工具 编写新的实用工具前，先搜索共享辅助程序包。 检查现有的数组、对象、字符串、URL、HTTP、JSON、Markdown、错误、文件、队列、格式化、正则表达式和测试辅助程序。直接复用适用的辅助程序。只有当现有行为都不匹配，并且多个使用方都能使用新的抽象时，才向共享包添加新的辅助程序。 不要在功能包中创建近似重复的实现。如果现有行为接近但并不完全相同，请先比较契约、边界情况、对捆绑产物的影响和调用位置，再决定是扩展现有实现，还是保留本地的领域专用函数。 ## 不用`any`，为函数和组件props标注类型 编写既能保持类型推断价值，又能明确公共契约的代码。 - 如果代码库标准有此规定，请优先使用类型别名和字符串字面量联合类型，而不是接口和枚举。 - 为函数指定明确的返回类型，使用`unknown`而不是`any`，标记仅类型导入，并默认使用不可变绑定。 - 保持直接导入；除有意设置的包入口点外，避免使用barrel文件，并避免通配符重新导出。 - 绝不要笼统地抑制类型错误。只有在理由能够证明错误是有意产生时，才使用预期错误指令。 - 处理每一个Promise；除非函数会等待某项工作，否则不要将其标记为异步函数。 - 在组件文件中，为属性和事件指定类型，通过解构设置默认值，将复杂的模板逻辑移到计算值中，并遵循既定的初始化顺序。 - 在注释和API文档中解释约束为何存在，不要只是复述代码。 ## 先测试受影响的包，而不是整个仓库 运行能够证明更改的最小测试范围。 1. 将单元测试放在其源文件旁边，并用对应文件的名称命名顶层测试套件。 2. 优先使用行为断言和纯函数；尽量减少模拟，并且当用户行为才是契约时，不要测试标记结构或样式细节。 3. 使用明确的路径筛选器运行一次受影响的包。仅在主动开发期间使用监视模式。 4. 对已更改的适配器运行集成测试，对受影响的用户流程运行端到端测试。 5. 启动所需的本地测试服务，并在依赖服务的测试开始前等待其就绪；单元测试绝不能使用真实网络。 6. 只有在有意进行最终集成检查或修改广泛的共享契约时，才运行整个单一代码仓库的测试套件。 单独处理与更改无关的既有失败：在更改范围外复现它们，如实报告，并且不要将其误称为环境成功或由本次更改导致的失败。 ## 对改动的文件运行lint，对受影响的包做类型检查 确定已更改文件的集合，并且只让每个工具处理其负责的语法。 - 对已更改的强类型语言文件运行该语言的代码检查器和格式化程序。 - 对已更改的组件、文档、数据、样式和配置文件运行组件代码检查器和通用格式化程序。 - 通过各自的工作区脚本对每个受影响的包进行类型检查。 - 在发起或更新评审前，扫描未使用的导出、文件和依赖项。 - 要求所有相关的代码检查、格式化、类型、测试和未使用代码检查全部无错误通过。 当包筛选器能够以更少的无关噪声提供更强的信号时，不要使用面向整个代码仓库的命令。基础配置发生变化，或者依赖关系分析显示存在多个下游使用方时，应扩大验证范围。 ## 按type(scope)格式写评审标题，并添加changeset 使用专用分支，并以惯用的现在时描述更改，同时包含相关的包作用域。 - 使用允许的更改类型，将评审标题写成语义形式`type(scope): subject`。 - 在评审说明中使用正确的关闭或非关闭关键字引用工单和议题；不要把必需的跟踪标识符埋在注释中。 - 提供跟踪链接时，添加专门的工单章节。 - 对可发布的包、集成或应用程序更改，检查发布说明状态，并在版本应当推进时添加patch或minor级别的changeset。不要通过常规流程引入major版本提升。 - 使用TODO让临时变通方案保持可见，并说明移除条件。 - 绝不要提交存在已知代码检查、类型、测试或未使用导出失败的更改。 ## 在能直接看到改动的试验环境中用截图检查UI更改 先构建上游包，再选择能够最直接呈现已更改行为的试验环境。 - 对基本控件使用组件目录，对渲染和导航使用文档界面，对编辑、身份验证、请求和响应使用客户端界面。 - 当共享组件、主题、语法渲染或图标会流入多个产品时，也要检查次要界面。 - 对修改后的UI截取更改前后截图，对新行为截取带上下文的截图，并为交互录制短视频。 - 使用具有描述性的产物名称，并将证据嵌入评审说明中专门的视觉章节。 - 如果一项更改影响多个界面或布局，请分别记录每个存在实质差异的结果，不要把一张截图当作通用证明。 视觉产物用于补充自动测试；它们不能取代行为断言、无障碍检查或类型验证。 ## 准确使用项目术语，只报告实际运行过的检查 在代码、文档、测试和评审文本中一致使用项目术语表。区分协议格式与API说明、数据模式与文档、解引用与解析，也要将打包与后两种操作区分开。 完成前： - 评审最终差异，并确认每个已更改文件都属于预期范围； - 视情况验证构建、测试、代码检查、格式化、类型、未使用代码扫描和视觉证据； - 确认包入口点、依赖项目录和changeset与实现一致； - 列出任何无法运行的检查，并保留其准确的失败证据； - 如果只运行了包范围内的检查，不要声称得到了整个单一代码仓库的结果。 报告受影响的包、执行的命令、直接结果、残余风险以及任何有意推迟的工作。