發佈工作流程

實驗性

此功能仍處於孵化階段，我們可能會根據您的意見回饋進行改進。

在使用 monorepo 時，一個困難的任務通常是找出在開始新版本時哪些套件應該接收新版本。Yarn 提供了一些工具，旨在讓這個工作流程更容易，而不需要第三方工具（儘管您可能更喜歡不同實作提供的不同工作流程，當然！）。

自動更新的相依性

在執行 yarn version 指令來升級工作區的版本時，透過基本 semver 範圍（^x.y.z、~x.y.z、...）依賴第一個工作區的每個其他工作區都將自動更新為參考新版本。例如，假設我們有以下工作區

/packages/common (1.0.0)
/packages/server (depends on common@^1.0.0)
/packages/client (depends on common@^1.0.0)

在 2.0 之前，升級 common 會要求您在那裡執行指令，然後進入 server 和 client 中的每個指令，手動升級其相依性以參考新版本。但現在不用了！如果我們在 common 中執行 yarn version 1.1.1，將套用以下變更

/packages/common (1.1.1)
/packages/server (depends on common@^1.1.1)
/packages/client (depends on common@^1.1.1)

當然，如果單元儲存庫中的套件總是打算作為單元儲存庫的一部分使用，這並不要緊，但當您使用多個打算發布的套件時，這會變得更有趣。如果您忘記更新依賴套件的範圍，您的使用者可能會下載舊版本的 common，而舊版本與新版本不相容。

延遲版本控制

從 2.0 開始，yarn version 命令現在接受新的標記：--deferred。設定此標記時，此命令不會立即變更本機清單的 version 欄位，而是改為在內部記錄一個條目，指出目前套件需要在下一個版本週期中接收升級。例如，下列

yarn version minor --deferred

不會造成 package.json 檔案變更！Yarn 會在 .yarn/versions 目錄中建立（或重複使用，如果您在分支中）一個檔案。此檔案會記錄請求的升級

releases:
  my-package@1.0.0: minor

然後稍後，當您準備好時，只要執行 yarn version apply。Yarn 會找到先前儲存的所有升級記錄，並一次套用所有記錄（包括處理我們看到的相互依賴升級）。

已簽入的延遲記錄

我們在上一節中看到 yarn version patch 可以將未來版本儲存在內部資料夾 .yarn/versions 中。但為什麼要這樣做？這樣做有什麼好處？要回答這個問題，請考慮一個透過單元儲存庫開發的熱門開源專案。此專案會收到許多外部拉取要求，但不會立即發布這些要求 - 這些要求通常會作為批次的一部分發布。每隔一段時間，主要維護人員會採用所有變更，將它們轉換為新版本，然後開始部署。

讓我們專注於必須將變更轉換為版本的部份。這要如何進行？這並不簡單。以 Lerna 為例（單一儲存庫最受歡迎的版本管理工具），您有兩種解決方案

• 在固定模式下，所有套件都有單一版本。因此，它們會一次全部升級。

• 在獨立模式下，您可以為來源已變更的每個套件選擇一個版本。

不過，仍然有一個關鍵問題：即使您使用獨立模式，您要如何知道哪些套件是要升級的？而且，同樣關鍵的是，它們應該是修補版本嗎？次要版本？很難知道 - 大型專案每週可能會收到數十個 PR，而追蹤哪些單元需要發布以及發布到哪個版本是一項相當困難的任務。

然而，使用 Yarn 的工作流程，這一切都會變得非常容易！由於升級會保存在檔案中，而且由於此檔案會神奇地繫結到 Git 分支，因此它只會變成提交發布資料夾的問題 - 所有預期的發布都將成為專案歷程記錄的一部分，直到 yarn version apply 的時間到來 - 然後 Yarn 會使用所有個別記錄，合併它們（因此需要次要版本的 PR 會比需要修補程式的 PR 優先），並同時套用它們。

作為額外好處，您甚至可以將套件升級當成一般 PR 檢閱的一部分來檢閱！這將產生將更多權力委派給您的社群的效果，同時能夠確保每個人都遵循規則。

確保版本升級（CI）

然而，提交延遲發布的一個問題是，確保您收到的公關包含正確的套件發布定義變得非常重要。例如，您應該能夠相信定義包含每個修改的工作區的發布策略（修補程式、次要、主要...）。

為了以自動化的方式解決這個問題，yarn version check 命令出現了。執行此命令時，它將找出哪些套件已變更，以及它們是否列在發布定義檔案中。如果沒有，將會擲回錯誤，並假設您將其整合到 CI 系統（例如 GitHub Actions）中，公關作者將被要求填寫發布定義檔案。

撰寫此檔案可能會很繁瑣；幸運的是 yarn version check 實作了一個名為 --interactive 的非常方便的標記。設定時 (yarn version check --interactive)，Yarn 將列印一個終端機介面，其中會摘要所有變更的檔案、所有變更的工作區、所有相關的依賴工作區，以及每個條目的核取方塊，讓您可以選擇要為每個工作區設定的發布策略。

在檢查哪些檔案已變更時，changesetIgnorePatterns 組態選項可用于忽略檔案。它對於排除不影響發布流程的檔案（例如測試檔案）很有用。

注意事項

提交記錄

版本外掛程式需要存取提交記錄，才能正確推斷哪些套件需要發布規格。特別是，在將 GitHub Actions 與 actions/checkout@v2 或更高版本一起使用時，預設行為是 Git 只擷取正在檢查的版本，這將導致問題。要修正這個問題，您需要覆寫 fetch-depth 組態值來擷取完整的提交記錄

- uses: actions/checkout@v2
  with:
    fetch-depth: 0