前往主要內容

Pull Request

請參閱 本機開發，了解如何開始在本地進行開發的詳細資訊。

所以你已在本地取得解決問題的變更代碼？太棒了！

請執行下列動作

請勿執行下列動作

  • 在開啟 PR 後進行強制推播
    • 理由：GitHub 無法追蹤強制推播中的變更，這會導致我們需要花更多時間來執行增量檢視
  • 針對現有的要求更新的 PR 發表評論
    • 理由：您的 PR 沒有被遺忘！志工維護者有時間限制來處理專案，它們會在能力所及時予以處理。
      • 例外情況：如果某個 PR 已遭封鎖並有問題待主要維護者回答超過 3 個月，請 ping 我們 — 我們可能遺漏了它。
  • 針對已關閉的 PR 發表評論
    • 理由：如果將事項以議題形式發布，則維護者不易遺漏它們。如果您認為 typescript-eslint 有錯誤，正確的詢問方式是 傳送新議題。議題範本包括實用 & 必要做法，例如確保您使用所有套件的最新版本。您可以提供相關 PR 的連結以增加脈絡資訊。

測試變更​

程式碼覆蓋率​

我們盡可能在所有 PR 中達到 100% 程式碼覆蓋率，但 website/ 套件除外。每當執行 yarn test 時，就會在本地產生覆蓋率報告。

codecov 機器人也會針對每個 PR 發表評論，說明其百分比，並提供 PR 所觸及的每個檔案的逐行覆蓋率連結。

細粒度單元測試​

大多數套件中的大多數測試都設定為小型、獨立的單元測試。我們通常會傾向如此，讓測試及其失敗報告保持細粒度。

在合理的情況下，我們建議對規則測試做以下設定

  • 在影響規則行為的大多數 PR 中，同時加入 valid 和 invalid 程式碼變更
  • 每個 invalid 個案限制為一個錯誤

提出 PR​

變更準備好之後，您便可以提出 PR 了！您的 PR 標題應符合以下格式

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

您可以在 針對 main 的近期提交記錄，找到更多良好過去 PR 標題的範例。

  • fix(範圍管理員)：修正類別靜態區塊的處理
  • 文件：修正 README.md 中關於入門的連結

在您的 PR 主體中，請務必點出您已處理的議題，並指出在我們的檢閱過程中希望我們注意的任何事項。

我們不在乎您歷史記錄中的提交數目或風格，因為我們會將每個 PR 合併至 main。歡迎使用您擅長或習慣的風格進行提交。

提示：傳送 PR 時，請從分支，而不是 main 傳送。請參閱 GitHub 的 提出更改文件 了解更多資訊。

類型​

必須符合下列其中一項

  • 文件 - 如果你只變更文件，而不是發放程式碼
  • 功能 - 新增任何新功能
  • 修復 - 修復任何沒有新增功能的錯誤
  • 測試 - 如果你只變更測試，而不是發放程式碼
  • 家事 - 其他所有事項

套件​

你在其中進行變更的套件名稱（例如 eslint-plugin、分析器、typescript-estree）。如果你跨多個套件進行重大變更，你可以省略（例如 功能：foo bar）。

簡短說明​

PR 的簡潔標題。

回應意見回饋和其他事項​

在你提出 PR 且 CI 通過後，你的 PR 會 在佇列中等待審查。我們通常會審查最早的 PR，除非我們認為較新的 PR 優先（例如，如果是錯誤修復）。

審查你的 PR 後，我們會提供任何需要處理的意見回饋。如果你覺得要求的變更不正確，不要害怕在意見中與我們討論。

請盡可能以 行意見 發佈意見，以便串接討論。你可以 解決對話，如果你覺得已經解決，不必明確意見或等待維護人員回覆。

在透過變更程式碼回應我們所有意見回饋或開始後續討論後，重新要求審查你回覆意見回饋的每一位維護人員。

在處理完意見回饋，且 PR 獲得核准後，我們會確保分支已更新至 main，並幫你合併。

隨著時間推移進行更新​

您通常不需要持續從 main 將 commit 合併至您的 PR 分支中。如果您看到合併衝突或其他令您擔心的交錯，您可以預先進行（選擇性）。

如果我們認為需要解決合併衝突才能合併和/或檢閱 PR，我們可能會做為一種禮貌為您執行此動作（取決於時間）。若時間不足，我們可能會要求您執行。

詢問問題​

如果您需要協助和/或有任何問題，在 PR 中貼文留言是很棒的方法。不需個別標註任何人。我們中的一位會在有空時協助您。

感謝備註

感謝您完整閱讀此檔案！請於您的 PR 底部附上您最喜歡的 emoji，告訴我們您已確實閱讀此檔案。如果您不確定要使用哪一個，💖 就很不錯。