在不破坏现有功能的前提下修改多包代码库

## 修改前，先确认负责这项变更的包和规则 编辑前，先确定仓库根目录、负责目标行为的包或子系统，以及距离目标最近且适用的贡献者说明。 - 将工作路由到能够正确处理它的最小范围。 - 阅读该范围所需的本地架构、约定、构建和测试资料。 - 对单个符号使用针对性搜索；对于跨文件调用方、导入项、重命名影响或较大的变更半径，则使用可用的依赖关系图。 - 根据已纳入版本控制的配置，确认运行时版本、包管理器版本、工作区定义和构建前提。 - 将链接或生成的说明文件视为其声明权威源的视图；只编辑权威源文件。 如果说明发生冲突或所有权不明确，应在写入前停止并准确指出冲突。调查期间不要修改无关的包。 ## 保留现有行为和公开名称，遵循现有架构 避免破坏现有用户的使用方式。除非已批准的变更明确要求，否则不要更改默认值或移除公开名称。让旧名称继续有效，并为弃用过程同时提供已记录的迁移方案和针对旧行为的测试。 遵守仓库已经建立的架构： - 将行为保留在其所属层或扩展边界内； - 核心契约发生变化时，保持各个官方适配器的功能一致； - 保留级联配置方式和公开的自定义契约； - 对用户可控内容进行净化处理，并避免污染全局命名空间； - 支持已声明的国际化和无障碍要求；以及 - 优先使用现有工具和最少的依赖项，而不是建立平行机制。 如果破坏兼容性的变更无法避免，应醒目标明，说明受影响的契约，并提供迁移路径。 ## 做最小的变更，并一起补上测试和文档 进行满足要求的最小且连贯的变更。遵循该包既有的代码、注释和文档风格。 对于行为变更： 1. 添加或更新聚焦的单元测试覆盖。 2. 当行为跨越边界时，添加适当的集成、浏览器或端到端测试覆盖。 3. 在依赖包测试之前，先运行所需的前置构建。 4. 针对受影响范围运行精简的代码检查、类型检查、样式检查和测试命令。 5. 当用户能够感知变更时，更新公开指南、API 参考、示例、迁移说明或变更日志条目。 6. 只有当变更引入持久约定、位置、约束或反复出现的陷阱时，才更新相应范围的贡献者说明。 缺少必要的测试覆盖或用户文档时，不要声称工作已经完成。记录所有无法运行的测试及其具体原因。 ## 添加依赖项前先获得批准，发布前再检查 添加第三方依赖项之前，先获得维护者批准。检查直接和传递依赖的许可证、维护状态、安全影响、打包或运行时成本，以及仓库是否已提供相同能力。 遵循仓库的分支、拉取请求、评审和变更日志约定。让变更历史便于评审，避免重写共享历史，并将无关工作分开。对于持续多天的工作，使用仓库认可的协作方式保留一个可见的检查点。 发布前，确认兼容性测试覆盖新旧行为、必要文档已经就位、生成产物处于最新状态，并且目标包变体或适配器已经过实际验证。 ## 报告运行了哪些测试和还剩哪些风险 返回一份简洁的验证报告，其中列出： - 变更的行为及其范围； - 受影响的文件或组件； - 已运行的测试、构建、代码检查和类型检查及其结果； - 兼容性与安全方面的考量； - 文档或变更日志更新；以及 - 未运行的项目、剩余风险和下一项必要操作。 将已验证结果与假设分开。任何破坏兼容性的变更或未完成的必要检查，都应在次要细节之前突出显示。