Oxc

PR のルールとポリシー ​

PR に関するルール ​

  • 小さめの PR を好む。
  • 書き込み権限があれば Graphite でスタックされた PR を試すとよいです。十分貢献すると権限が付与されます。
  • アーキテクチャ変更を含む PR では、先に Issue または Discussion を作成してください。

開発ポリシー ​

  • データ指向設計を採用する。
  • API はシンプルで、ドキュメントが揃っていること。
  • 他プロジェクト由来の実装には必ず出典を示す。

パフォーマンス ​

  • ランタイム・コンパイルを含む性能問題はすべてバグとみなす。
    • Rust Performance Book の指針に従う。
    • regex クレートの利用は最小限に。イテレータや文字列メソッドを優先する。
  • 開発フローや下流ツールへの影響を減らすため、コンパイル時間を抑える。
    • サードパーティ依存を減らし、コンパイル速度と複雑さを抑える。
    • コンパイルやバイナリサイズを悪化させる重いマクロ・ジェネリクス等は避ける。
    • CI は約 3 分で完了する想定であり、劣化は修正が必要。

メンテナンス方針 ​

  • コードカバレッジを監視し、未使用コードに注意する。目標は約 99% カバレッジ。
  • CI 時間を短縮して PR マージを加速する。現状 GitHub Actions は約 3 分。
  • ドキュメントファースト。ドキュメントを真実の情報源にし、更新を維持し、同じ質問への繰り返し回答ではなくリンクを貼る。GitLab の handbook-first の考え方に近い。
  • import の並び順は「遠いもの」から「近いもの」へ。
    • std
    • 外部クレート
    • Oxc クレート
    • 同一クレート内の crate
    • super
    • mod

Conventional Commits ​

Conventional Commits に従います。

コミットには意図を伝えるための構造要素があります。

  • fix: バグ修正
  • feat: 新機能
  • BREAKING CHANGE: 型やスコープのあとに ! を付け互換を壊す API 変更、例 feat(parser)!: new feature
  • スコープはクレート名
  • 型は feat:、fix:、chore:、ci:、docs:、style:、refactor:、perf:、test: など

アクションの方針 ​

Astral の価値観 より：

不確実さがあっても行動を優先する。議論を長引かせるより 実務的に動く ことを選び、許可を求めるより 事後の説明 を選ぶ。決定がはっきりしないとき、特に 取り消し可能 な決定ほど、決断力を重視する。

行動志向は無謀と同じではない。責任ある判断をし、曖昧さや既知の未知が残っていても 速やかに 実行することだ。

© 2026 VoidZero Inc. and Oxc contributors.