PR 规则与政策

PR 惯例

• 我们更偏好小而精的 PR。
• 若你有写权限且有较大改动，可尝试用 Graphite 做堆栈式 PR。
• 若包含架构层面的变更，请先开 Issue 或 Discussion。

开发政策

• 拥抱面向数据（data-oriented）的设计思路。
• 保持 API 简单并有文档说明。
• 若实现参考了其它项目，请标注出处。

性能

• 运行时与编译时性能问题均视作本项目的 Bug。
  • 参考 The Rust Performance Book。
  • 尽量减少 regex crate 的使用，多用迭代器与字符串方法。
• 编译时间必须尽量压低，以降低对开发与下游的影响。
  • 精简第三方依赖。
  • 慎用重度宏、泛型或其它会拖累编译／膨胀二进制体积的技巧。
  • CI 全流程约在 3 分钟内完成；若拖累 CI 时间必须修复。

维护政策

• 关注覆盖率，尽量减少死代码；目标约 99% 覆盖率。
• 积极缩短 CI，加快 PR 合入（当前 GitHub Actions 全流程约 3 分钟）。
• 文档先行：文档应当是事实来源保持更新并分享链接，避免在同一问题上反复口头回答。可参考 GitLab 的 手册优先（handbook-first）理念。
• 导入顺序：std → 外部 crate → Oxc crate → 本地 crate:: → super → mod，从「最远」到「最近」一致排列。

Conventional Commits

遵循 Conventional Commits：

• fix：修复 Bug。
• feat：新功能。
• BREAKING CHANGE：在类型/scope 后加 !，表示破坏性变更，例如 feat(parser)!: ...。
• scope 通常为 crate 名。
• 类型：feat、fix、chore、ci、docs、style、refactor、perf、test 等。

Action 取向

改编自 Astral 的价值观：

我们宁可先行动，即使面对不确定性。我们更看重务实的动手，而不是无休止的争辩；更看重先做再解释，而不是事事请示。果断决策本身就很有价值——尤其当抉择本身难以厘清、但可以撤销时更是如此。

倾向行动 不等于鲁莽；它是指带着责任感、以紧迫感推进，即使在仍有模糊或未解之处时仍能做出负责任的决策。