Bzlmod 遷移指南

由於 WORKSPACE 有缺點，Bzlmod 將取代舊版 WORKSPACE 系統。Bazel 8 (2024 年底) 已停用 WORKSPACE 檔案，Bazel 9 (2025 年底) 則會移除該檔案。本指南可協助您將專案遷移至 Bzlmod，並捨棄 WORKSPACE 來管理外部依附元件。

為什麼要遷移至 Bzlmod？

• 與舊版 WORKSPACE 系統相比，有許多優點，有助於確保 Bazel 生態系統健康成長。

• 如果您的專案是其他專案的依附元件，遷移至 Bzlmod 可解除這些專案的遷移作業，並讓這些專案更容易依附您的專案。

• 如要使用日後的 Bazel 版本 (Bazel 9 必須使用 Bzlmod)，就必須遷移至 Bzlmod。

如何遷移至 Bzlmod？

建議的遷移程序：

1. 使用遷移工具做為輔助工具，盡可能簡化遷移程序。
2. 如果使用遷移工具後仍有錯誤，請手動解決。如要瞭解 WORKSPACE 和 MODULE.bazel 檔案中概念的主要差異，請參閱「WORKSPACE 與 Bzlmod」一節。

WORKSPACE 與 Bzlmod

Bazel 的 WORKSPACE 和 Bzlmod 提供類似功能，但語法不同。本節說明如何從特定 WORKSPACE 功能遷移至 Bzlmod。

定義 Bazel 工作區的根目錄

WORKSPACE 檔案會標示 Bazel 專案的來源根目錄，但從 Bazel 6.3 版開始，這項責任會由 MODULE.bazel 取代。如果 Bazel 版本早於 6.3，工作區根目錄中應該仍有 WORKSPACE 或 WORKSPACE.bazel 檔案，可能含有類似下列的註解：

• WORKSPACE

  # This file marks the root of the Bazel workspace.
  # See MODULE.bazel for external dependencies setup.
  

在 bazelrc 中啟用 Bzlmod

.bazelrc 可讓您設定每次執行 Bazel 時套用的標記。如要啟用 Bzlmod，請使用 --enable_bzlmod 旗標，並將其套用至 common 指令，以便套用至每個指令：

• .bazelrc

  # Enable Bzlmod for every Bazel command
  common --enable_bzlmod
  

指定工作區的存放區名稱

• WORKSPACE

  workspace 函式用於指定工作區的存放區名稱。這樣一來，工作區中的目標 //foo:bar 就能以 @<workspace name>//foo:bar 參照。如未指定，工作區的預設存放區名稱為 __main__。

  ## WORKSPACE
  workspace(name = "com_foo_bar")
  

• Bzlmod

  建議您使用 //foo:bar 語法參照相同工作區中的目標，但不要使用 @<repo name>。但如果需要舊版語法，可以使用 module 函式指定的模組名稱做為存放區名稱。如果模組名稱與所需存放區名稱不同，可以使用 module 函式的 repo_name 屬性覆寫存放區名稱。

  ## MODULE.bazel
  module(
      name = "bar",
      repo_name = "com_foo_bar",
  )
  

以 Bazel 模組形式擷取外部依附元件

如果依附元件是 Bazel 專案，且也採用 Bzlmod，您應該可以將其視為 Bazel 模組。

• WORKSPACE

  使用 WORKSPACE 時，通常會使用 http_archive 或 git_repository 存放區規則，下載 Bazel 專案的來源。

  ## WORKSPACE
  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
  
  http_archive(
      name = "bazel_skylib",
      urls = ["https://github.com/bazelbuild/bazel-skylib/releases/download/1.4.2/bazel-skylib-1.4.2.tar.gz"],
      sha256 = "66ffd9315665bfaafc96b52278f57c7e2dd09f5ede279ea6d39b2be471e7e3aa",
  )
  load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace")
  bazel_skylib_workspace()
  
  http_archive(
      name = "rules_java",
      urls = ["https://github.com/bazelbuild/rules_java/releases/download/6.1.1/rules_java-6.1.1.tar.gz"],
      sha256 = "76402a50ae6859d50bd7aed8c1b8ef09dae5c1035bb3ca7d276f7f3ce659818a",
  )
  load("@rules_java//java:repositories.bzl", "rules_java_dependencies", "rules_java_toolchains")
  rules_java_dependencies()
  rules_java_toolchains()
  

  如您所見，使用者需要從依附元件的巨集載入遞移依附元件，這是常見模式。假設 bazel_skylib 和 rules_java 都依附於 platform，則 platform 依附元件的確切版本取決於巨集的順序。

• Bzlmod

  使用 Bzlmod 時，只要依附元件位於 Bazel Central Registry 或自訂 Bazel 登錄檔，您就能透過 bazel_dep 指令依附該元件。

  ## MODULE.bazel
  bazel_dep(name = "bazel_skylib", version = "1.4.2")
  bazel_dep(name = "rules_java", version = "6.1.1")
  

  Bzlmod 會使用 MVS 演算法，以遞移方式解析 Bazel 模組依附元件。因此，系統會自動選取 platform 的最高必要版本。

以 Bazel 模組覆寫依附元件

做為根模組，您可以透過不同方式覆寫 Bazel 模組依附元件。

詳情請參閱「覆寫」一節。

您可以在 examples 存放區中找到一些使用範例。

使用模組擴充功能擷取外部依附元件

如果依附元件不是 Bazel 專案，或尚未在任何 Bazel 登錄檔中提供，您可以使用 use_repo_rule 或模組擴充功能導入。

• WORKSPACE

  使用 http_file 存放區規則下載檔案。

  ## WORKSPACE
  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
  
  http_file(
      name = "data_file",
      url = "http://example.com/file",
      sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  )
  

• Bzlmod

  使用 Bzlmod 時，您可以在 MODULE.bazel 檔案中使用 use_repo_rule 指令，直接例項化 repo：

  ## MODULE.bazel
  http_file = use_repo_rule("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
  http_file(
      name = "data_file",
      url = "http://example.com/file",
      sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  )
  

  這項功能在幕後是透過模組擴充功能實作。如果您需要執行比單純叫用存放區規則更複雜的邏輯，也可以自行實作模組擴充功能。您需要將定義移至 .bzl 檔案，這樣在遷移期間，您也能在 WORKSPACE 和 Bzlmod 之間共用定義。

  ## repositories.bzl
  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
  def my_data_dependency():
      http_file(
          name = "data_file",
          url = "http://example.com/file",
          sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      )
  

  實作模組擴充功能，載入依附元件巨集。您可以在巨集的相同 .bzl 檔案中定義，但為了與舊版 Bazel 保持相容性，建議在個別的 .bzl 檔案中定義。

  ## extensions.bzl
  load("//:repositories.bzl", "my_data_dependency")
  def _non_module_dependencies_impl(_ctx):
      my_data_dependency()
  
  non_module_dependencies = module_extension(
      implementation = _non_module_dependencies_impl,
  )
  

  如要讓根專案看得到存放區，請在 MODULE.bazel 檔案中宣告模組擴充功能和存放區的用法。

  ## MODULE.bazel
  non_module_dependencies = use_extension("//:extensions.bzl", "non_module_dependencies")
  use_repo(non_module_dependencies, "data_file")
  

使用模組擴充功能解決外部依附元件的衝突

專案可以提供巨集，根據呼叫端的輸入內容導入外部存放區。但如果依附元件圖表中有許多呼叫端，且這些呼叫端造成衝突，該怎麼辦？

假設專案 foo 提供下列巨集，並以 version 做為引數。

## repositories.bzl in foo {:#repositories.bzl-foo}
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
def data_deps(version = "1.0"):
    http_file(
        name = "data_file",
        url = "http://example.com/file-%s" % version,
        # Omitting the "sha256" attribute for simplicity
    )

• WORKSPACE

  您可以使用 WORKSPACE 從 @foo 載入巨集，並指定所需的資料依附元件版本。假設您有另一個依附元件 @bar，該元件也依附於 @foo，但需要不同版本的資料依附元件。

  ## WORKSPACE
  
  # Introduce @foo and @bar.
  ...
  
  load("@foo//:repositories.bzl", "data_deps")
  data_deps(version = "2.0")
  
  load("@bar//:repositories.bzl", "bar_deps")
  bar_deps() # -> which calls data_deps(version = "3.0")
  

  在這種情況下，使用者必須仔細調整 WORKSPACE 中的巨集順序，才能取得所需版本。這是 WORKSPACE 的一大痛點，因為它並未提供解決依附元件的合理方式。

• Bzlmod

  使用 Bzlmod 時，專案 foo 的作者可以運用模組擴充功能解決衝突。舉例來說，假設在所有 Bazel 模組中，一律選取資料依附元件的最大必要版本是合理的做法。

  ## extensions.bzl in foo
  load("//:repositories.bzl", "data_deps")
  
  data = tag_class(attrs={"version": attr.string()})
  
  def _data_deps_extension_impl(module_ctx):
      # Select the maximal required version in the dependency graph.
      version = "1.0"
      for mod in module_ctx.modules:
          for data in mod.tags.data:
              version = max(version, data.version)
      data_deps(version)
  
  data_deps_extension = module_extension(
      implementation = _data_deps_extension_impl,
      tag_classes = {"data": data},
  )
  

  ## MODULE.bazel in bar
  bazel_dep(name = "foo", version = "1.0")
  
  foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension")
  foo_data_deps.data(version = "3.0")
  use_repo(foo_data_deps, "data_file")
  

  ## MODULE.bazel in root module
  bazel_dep(name = "foo", version = "1.0")
  bazel_dep(name = "bar", version = "1.0")
  
  foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension")
  foo_data_deps.data(version = "2.0")
  use_repo(foo_data_deps, "data_file")
  

  在這種情況下，根模組需要資料版本 2.0，而其依附元件 bar 則需要 3.0。foo 中的模組擴充功能可正確解決這項衝突，並自動選取資料依附元件的 3.0 版本。

整合第三方套件管理工具

如上一節所述，模組擴充功能可從依附元件圖收集資訊、執行自訂邏輯來解析依附元件，並呼叫存放區規則來導入外部存放區，因此規則作者可藉此強化整合特定語言套件管理工具的規則集。

請參閱模組擴充功能頁面，進一步瞭解如何使用模組擴充功能。

以下列出已採用 Bzlmod 從不同套件管理工具擷取依附元件的規則集：

• rules_jvm_external
• rules_go
• rules_python

如需整合虛擬套件管理員的簡短範例，請參閱 examples 存放區。

偵測主機上的工具鍊

當 Bazel 建構規則需要偵測主機上可用的工具鍊時，會使用存放區規則檢查主機，並以外部存放區的形式產生工具鍊資訊。

• WORKSPACE

  假設有下列存放區規則，可偵測殼層工具鍊。

  ## local_config_sh.bzl
  def _sh_config_rule_impl(repository_ctx):
      sh_path = get_sh_path_from_env("SH_BIN_PATH")
  
      if not sh_path:
          sh_path = detect_sh_from_path()
  
      if not sh_path:
          sh_path = "/shell/binary/not/found"
  
      repository_ctx.file("BUILD", """
  load("@bazel_tools//tools/sh:sh_toolchain.bzl", "sh_toolchain")
  sh_toolchain(
      name = "local_sh",
      path = "{sh_path}",
      visibility = ["//visibility:public"],
  )
  toolchain(
      name = "local_sh_toolchain",
      toolchain = ":local_sh",
      toolchain_type = "@bazel_tools//tools/sh:toolchain_type",
  )
  """.format(sh_path = sh_path))
  
  sh_config_rule = repository_rule(
      environ = ["SH_BIN_PATH"],
      local = True,
      implementation = _sh_config_rule_impl,
  )
  

  您可以在 WORKSPACE 中載入存放區規則。

  ## WORKSPACE
  load("//:local_config_sh.bzl", "sh_config_rule")
  sh_config_rule(name = "local_config_sh")
  

• Bzlmod

  使用 Bzlmod 時，您可以透過模組擴充功能導入相同存放區，類似於上一節中導入 @data_file 存放區。

  ## local_config_sh_extension.bzl
  load("//:local_config_sh.bzl", "sh_config_rule")
  
  sh_config_extension = module_extension(
      implementation = lambda ctx: sh_config_rule(name = "local_config_sh"),
  )
  

  接著在 MODULE.bazel 檔案中使用擴充功能。

  ## MODULE.bazel
  sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension")
  use_repo(sh_config_ext, "local_config_sh")
  

註冊工具鍊和執行平台

如最後一節所述，導入存放區代管工具鍊資訊 (例如 local_config_sh) 後，您可能想註冊工具鍊。

• WORKSPACE

  您可以使用 WORKSPACE，透過下列方式註冊工具鍊。

  1. 您可以在 .bzl 檔案中註冊工具鍊，並在 WORKSPACE 檔案中載入巨集。

     ## local_config_sh.bzl
     def sh_configure():
         sh_config_rule(name = "local_config_sh")
         native.register_toolchains("@local_config_sh//:local_sh_toolchain")
     

     ## WORKSPACE
     load("//:local_config_sh.bzl", "sh_configure")
     sh_configure()
     

  2. 或直接在 WORKSPACE 檔案中註冊工具鍊。

     ## WORKSPACE
     load("//:local_config_sh.bzl", "sh_config_rule")
     sh_config_rule(name = "local_config_sh")
     register_toolchains("@local_config_sh//:local_sh_toolchain")
     

• Bzlmod

  使用 Bzlmod 時，register_toolchains 和 register_execution_platforms API 僅適用於 MODULE.bazel 檔案。您無法在模組擴充功能中呼叫 native.register_toolchains。

  ## MODULE.bazel
  sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension")
  use_repo(sh_config_ext, "local_config_sh")
  register_toolchains("@local_config_sh//:local_sh_toolchain")
  

在 WORKSPACE、WORKSPACE.bzlmod 和每個 Bazel 模組的 MODULE.bazel 檔案中註冊的工具鍊和執行平台，在工具鍊選取期間會遵循下列優先順序 (由高至低)：

1. 在根模組的 MODULE.bazel 檔案中註冊的工具鍊和執行平台。
2. 在 WORKSPACE 或 WORKSPACE.bzlmod 檔案中註冊的工具鍊和執行平台。
3. 由根模組的 (遞移) 依附元件註冊的工具鍊和執行平台。
4. 未使用 WORKSPACE.bzlmod 時：在 WORKSPACE suffix 中註冊的工具鍊。

介紹本機存放區

如果需要依附元件的本機版本進行偵錯，或是想將工作區中的目錄併入為外部存放區，您可能需要將依附元件做為本機存放區導入。

• WORKSPACE

  使用 WORKSPACE 時，可透過兩個原生存放區規則 local_repository 和 new_local_repository 達成此目的。

  ## WORKSPACE
  local_repository(
      name = "rules_java",
      path = "/Users/bazel_user/workspace/rules_java",
  )
  

• Bzlmod

  使用 Bzlmod 時，您可以透過 local_path_override 使用本機路徑覆寫模組。

  ## MODULE.bazel
  bazel_dep(name = "rules_java")
  local_path_override(
      module_name = "rules_java",
      path = "/Users/bazel_user/workspace/rules_java",
  )
  

  您也可以透過模組擴充功能導入本機存放區。不過，您無法在模組擴充功能中呼叫 native.local_repository，目前我們正努力將所有原生存放區規則 Starlark 化 (請參閱 #18285，瞭解進度)。接著，您可以在模組擴充功能中呼叫對應的 Starlark local_repository。如果這是您的阻礙問題，實作自訂版本的 local_repository 存放區規則也很簡單。

繫結目標

WORKSPACE 中的 bind 規則已淘汰，Bzlmod 不支援這項規則。這項功能是為了在特殊 //external 套件中為目標指定別名而推出。依附於此的所有使用者都應遷移。

舉例來說

## WORKSPACE
bind(
    name = "openssl",
    actual = "@my-ssl//src:openssl-lib",
)

這樣一來，其他目標就能依附於 //external:openssl。如要遷移，請按照下列步驟操作：

• 將所有 //external:openssl 用法替換為 @my-ssl//src:openssl-lib。

  • 提示：使用 bazel query --output=build --noenable_bzlmod --enable_workspace [target] 指令尋找目標的相關資訊。

• 或使用 alias 建構規則

  • 在套件 (例如 //third_party) 中定義下列目標

    ## third_party/BUILD
    alias(
        name = "openssl",
        actual = "@my-ssl//src:openssl-lib",
    )
    

  • 將所有 //external:openssl 用法替換為 //third_party:openssl。

擷取與同步

擷取和同步指令可用於在本機下載外部存放區，並保持最新狀態。有時也會在擷取建構作業所需的所有存放區後，使用 --nofetch 標記離線建構。

• WORKSPACE

  同步會強制擷取所有存放區或特定設定的存放區集，而擷取只用於擷取特定目標。

• Bzlmod

  同步指令已不適用，但擷取提供各種選項。 您可以擷取目標、存放區、一組已設定的存放區，或參與依附元件解析和模組擴充功能的所有存放區。擷取結果會快取，如要強制擷取，必須在擷取程序中加入 --force 選項。

手動遷移

本節提供實用資訊和指南，協助您手動進行 Bzlmod 遷移程序。如要瞭解更自動化的遷移程序，請參閱「建議的遷移程序」一節。

瞭解 WORKSPACE 中的依附元件

遷移的第一步是瞭解您有哪些依附元件。由於遞移依附元件通常會透過 *_deps 巨集載入，因此可能難以判斷 WORKSPACE 檔案中導入的確切依附元件。

使用工作區已解析的檔案檢查外部依附元件

幸好，旗標 --experimental_repository_resolved_file 可以派上用場。這個標記基本上會為上一個 Bazel 指令中擷取的所有外部依附元件產生「鎖定檔案」。詳情請參閱這篇網誌文章。

使用方法有兩種：

1. 擷取建構特定目標所需的外部依附元件資訊。

   bazel clean --expunge
   bazel build --nobuild --experimental_repository_resolved_file=resolved.bzl //foo:bar
   

2. 擷取 WORKSPACE 檔案中定義的所有外部依附元件資訊。

   bazel clean --expunge
   bazel sync --experimental_repository_resolved_file=resolved.bzl
   

   您可以使用 bazel sync 指令擷取 WORKSPACE 檔案中定義的所有依附元件，包括：

   • bind用量
   • register_toolchains和register_execution_platforms用量

   不過，如果專案是跨平台，bazel 同步可能會在特定平台上中斷，因為部分存放區規則可能只會在支援的平台上正確執行。

執行指令後，resolved.bzl 檔案中應該會顯示外部依附元件的資訊。

使用 bazel query 檢查外部依附元件

您可能也知道 bazel query 可用於檢查存放區規則，

bazel query --output=build //external:<repo name>

雖然更方便且速度快得多，但 bazel 查詢可能會謊報外部依附元件版本，因此請謹慎使用！使用 Bzlmod 查詢及檢查外部依附元件時，會用到新的子指令。

內建預設依附元件

如果您檢查 --experimental_repository_resolved_file 產生的檔案，會發現許多未在 WORKSPACE 中定義的依附元件。這是因為 Bazel 實際上會在使用者 WORKSPACE 檔案內容中加入前置字元和後置字元，以插入一些通常是原生規則 (例如 @bazel_tools、@platforms 和 @remote_java_tools) 所需的預設依附元件。使用 Bzlmod 時，這些依附元件會透過內建模組 bazel_tools 導入，這是所有其他 Bazel 模組的預設依附元件。

混合模式，可逐步遷移

Bzlmod 和 WORKSPACE 可以並存，因此從 WORKSPACE 檔案移轉至 Bzlmod 的依附元件可逐步完成。

WORKSPACE.bzlmod

在遷移期間，Bazel 使用者可能需要在啟用和未啟用 Bzlmod 的建構作業之間切換。導入 WORKSPACE.bzlmod 支援功能，讓程序更順暢。

WORKSPACE.bzlmod 的語法與 WORKSPACE 完全相同。啟用 Bzlmod 時，如果工作區根目錄中也有 WORKSPACE.bzlmod 檔案：

• WORKSPACE.bzlmod 會生效，而 WORKSPACE 的內容則會遭到忽略。
• 不會在 WORKSPACE.bzlmod 檔案中新增前置或後置字串。

使用 WORKSPACE.bzlmod 檔案可簡化遷移作業，原因如下：

• 停用 Bzlmod 後，系統會改為從原始 WORKSPACE 檔案擷取依附元件。
• 啟用 Bzlmod 後，您可以使用 WORKSPACE.bzlmod 更輕鬆地追蹤要遷移的依附元件。

存放區瀏覽權限

Bzlmod 可控管特定存放區可見的其他存放區，詳情請參閱存放區名稱和嚴格依附元件。

下表摘要說明不同類型存放區的存放區可見度，並考量工作區。

手動遷移程序

典型的 Bzlmod 遷移程序如下所示：

1. 瞭解您在 WORKSPACE 中的依附元件。
2. 在專案根層級新增空白的 MODULE.bazel 檔案。
3. 新增空白的 WORKSPACE.bzlmod 檔案，覆寫 WORKSPACE 檔案內容。
4. 啟用 Bzlmod 後建構目標，並檢查缺少哪個存放區。
5. 在已解決的依附元件檔案中，檢查遺失存放區的定義。
6. 透過模組擴充功能，以 Bazel 模組的形式導入缺少的依附元件，或將其保留在 WORKSPACE.bzlmod 中，以便稍後遷移。
7. 返回步驟 4 並重複操作，直到所有依附元件都可用為止。

發布 Bazel 模組

如果您的 Bazel 專案是其他專案的依附元件，可以在 Bazel Central Registry 中發布專案。

如要在 BCR 中簽入專案，您需要專案的來源封存網址。建立來源封存時，請注意下列幾點：

• 確認封存檔指向特定版本。

  BCR 只能接受已設定版本的來源封存檔，因為 Bzlmod 需要在依附元件解析期間進行版本比較。

• 確認封存網址穩定。

  Bazel 會透過雜湊值驗證封存內容，因此請確保下載檔案的總和檢查碼不會變更。如果網址來自 GitHub，請在發布頁面中建立並上傳發布封存檔。GitHub 不會保證隨選產生的來源封存檔的總和檢查碼。簡而言之，https://github.com/<org>/<repo>/releases/download/... 形式的網址視為穩定，https://github.com/<org>/<repo>/archive/... 則否。如需更多背景資訊，請查看 GitHub 封存檢查碼 中斷。

• 確認來源樹狀結構遵循原始存放區的版面配置。

  如果存放區非常大，且您想建立大小縮減的發布封存檔 (方法是移除不必要的來源)，請務必確認移除後的來源樹狀結構是原始來源樹狀結構的子集。這樣一來，使用者就能更輕鬆地透過 archive_override 和 git_override，將模組覆寫為非發布版本。

• 在子目錄中加入測試最常見 API 的測試模組。

  測試模組是 Bazel 專案，在來源封存檔的子目錄中，有自己的 WORKSPACE 和 MODULE.bazel 檔案，依附於要發布的實際模組。其中應包含範例或一些涵蓋最常見 API 的整合測試。請參閱測試模組，瞭解如何設定。

準備好來源封存網址後，請按照 BCR 貢獻指南，透過 GitHub Pull Request 將模組提交至 BCR。

強烈建議為存放區設定「Publish to BCR」 GitHub 應用程式，自動將模組提交至 BCR。

最佳做法

本節列舉幾項最佳做法，建議您遵循這些做法，以便更妥善地管理外部依附元件。

將目標分割成不同的套件，避免擷取不必要的依附元件。

請參閱 #12835，瞭解測試的開發依附元件為何會強制擷取，以建構不需要這些元件的目標。這實際上並非 Bzlmod 專屬，但遵循這些做法可更輕鬆地正確指定開發依附元件。

指定開發依附元件

您可以將 dev_dependency 屬性設為 true，用於 bazel_dep 和 use_extension 指令，這樣這些指令就不會傳播至依附專案。做為根模組，您可以使用 --ignore_dev_dependency 旗標，確認目標是否仍可建構，且沒有開發依附元件和覆寫。

社群遷移進度

您可以查看 Bazel Central Registry，瞭解依附元件是否已可使用。否則，歡迎加入這項 GitHub 討論，投下贊成票或發布阻礙遷移作業的依附元件。

回報問題

請查看 Bazel GitHub 問題清單，瞭解 Bzlmod 已知問題。歡迎提出新問題或要求新功能，協助您順利完成遷移！