メインコンテンツにスキップ

プルリクエスト

ローカルでの開発を始める方法については、ローカル開発をご覧ください。

問題を解決する変更をローカルで行いましたか？素晴らしい！

必ず

しないでください

  • PRを開いた後に強制プッシュしないでください
    • 理由：GitHubは強制プッシュによる変更を追跡できないため、段階的なレビューに時間がかかります
  • 既存のPRに更新を求めるコメントをしないでください
    • 理由：あなたのPRは忘れられていません！ボランティアのメンテナーはプロジェクトに取り組む時間が限られており、できるだけ早く対応します。
      • 例外：PRがメンテナーへの質問で3か月以上ブロックされている場合は、ご連絡ください。おそらく見失っています。
  • クローズされたPRにコメントしないでください
    • 理由：Issueとして投稿された方が、メンテナーが物事を見失わないためにずっと簡単です。typescript-eslintにバグがあると思われる場合は、新しいIssueを提出するのが適切な方法です。Issueテンプレートには、すべてのパッケージの最新バージョンを使用していることを確認するなど、役立つ必要なプラクティスが含まれています。関連するPRへのリンクを提供して、より多くのコンテキストを追加できます。

変更のテスト​

コードカバレッジ​

website/ パッケージを除き、可能な限りすべてのPRで100%のコードカバレッジを目指しています。カバレッジレポートは、yarn test が実行されるたびにローカルで生成されます。

codecov ボットは、各PRにそのパーセンテージと、PRによって影響を受けた各ファイルの行ごとのカバレッジへのリンクをコメントします。

詳細な単体テスト​

ほとんどのパッケージのほとんどのテストは、小さく自己完結型の単体テストとして設定されています。一般に、テストとその失敗レポートを詳細に保つことを優先します。

ルールテストについては、合理的な範囲で推奨します

  • ルール動作に影響を与えるほとんどのPRに、valid と invalid の両方のコード変更を含める
  • invalid ケースごとに1つのエラーに制限する

PRの発行​

変更が完了したら、PRを発行できます！🙌 PRのタイトルは次の形式と一致する必要があります

<type>(<package>): <short description>

mainへの最近のコミットで、過去の良いPRタイトルのサンプルをさらに見つけることができます

  • fix(scope-manager): クラス静的ブロックの正しい処理
  • docs: README.mdの開始方法へのリンクを修正

PRの本文内で、作業したIssueを参照し、レビュー中に見てほしい注目すべき点を指摘してください。

すべてのPRをmainにスカッシュマージするため、履歴のコミット数やスタイルは気にしません。快適なスタイルで自由にコミットしてください。

ヒント：main以外のブランチからPRを送信します。詳細については、GitHubの変更提案ドキュメントを参照してください。

type​

次のいずれかである必要があります

  • docs - ドキュメントのみを変更し、出荷コードを変更しない場合
  • feat - 新しい機能を追加する場合
  • fix - 新しい機能を追加しないバグ修正の場合
  • test - テストのみを変更し、出荷コードを変更しない場合
  • chore - その他

package​

変更を加えたパッケージの名前（例：eslint-plugin、parser、typescript-estree）。複数のパッケージにわたって大幅な変更を加える場合は、これを省略できます（例：feat: foo bar）。

短い説明​

PRの簡潔なタイトル。

フィードバックへの対応とそれ以降​

PRが発行され、CIが合格すると、PRはレビュー待ちのキューに入ります。一般的に、新しいPRを優先度が高いと見なす場合（バグ修正の場合など）を除き、最も古いPRから最新のPRへとレビューします。

PRをレビューしたら、対応する必要のあるフィードバックを提供します。要求された変更が間違っていると感じた場合は、コメントで議論することを恐れないでください。

可能な場合は行コメントとしてコメントを投稿して、スレッド化できるようにしてください。解決したと感じたら、明示的にコメントしたり、メンテナーを待ったりする必要はなく、自分で会話を解決できます。

コードの変更と/またはフォローアップディスカッションを開始することにより、すべてのフィードバックに対応したら、フィードバックに対応した各メンテナーに再レビューをリクエストしてください。

フィードバックが処理され、PRが承認されたら、ブランチがmainと最新の状態であることを確認し、マージします。

時間の経過に伴う更新​

一般的に、mainからPRブランチにコミットをマージし続ける必要はありません。マージ競合やその他の気になる交差がある場合は、予防的に行うことができますが、それはオプションです。

PRをマージおよび/またはレビューするためにマージ競合を解決する必要があると思われる場合は、時間があれば、便宜上それを行う可能性があります。そうでない場合は、お願いするかもしれません。

質問をする​

ヘルプが必要な場合や質問がある場合は、PRにコメントを投稿するのが最適な方法です。誰かを個別にタグ付けする必要はありません。可能な場合は、誰かが立ち寄って助けてくれます。

感謝のメモ

このファイルを最後まで読んでいただきありがとうございます！このファイルを実際に読んだことを示すために、プルリクエストの一番下に好きな絵文字を含めてください。どの絵文字を使用すればよいかわからない場合は、💖がおすすめです。