Bazel 模块是一个可以有多个版本的 Bazel 项目，每个版本都会发布有关其所依赖的其他模块的元数据。这类似于其他依赖项管理系统中的熟悉概念，例如 Maven 工件、npm 软件包、Go 模块 或 Cargo 箱。
模块必须在其代码库根目录（WORKSPACE 文件旁边）中包含 MODULE.bazel 文件。此文件是模块的清单，用于声明模块的名称、版本、直接依赖项列表和其他信息。举个基本示例：
module(name = "my-module", version = "1.0")
bazel_dep(name = "rules_cc", version = "0.0.1")
bazel_dep(name = "protobuf", version = "3.19.0")
查看 MODULE.bazel 文件中可用的指令的完整列表。
为了执行模块解析，Bazel 首先会读取根模块的 MODULE.bazel 文件，然后反复从 Bazel 注册表请求任何依赖项的 MODULE.bazel 文件，直到发现整个依赖关系图。
默认情况下，Bazel 随后会选择每个模块的一个版本来使用。Bazel 使用一个代码库来表示每个模块，并再次查询注册表，以了解如何定义每个代码库。
版本格式
Bazel 拥有多样化的生态系统，项目使用各种版本控制方案。目前最受欢迎的是 SemVer，但也有一些知名项目使用不同的方案，例如 Abseil（其版本基于日期，例如 20210324.2）。
为此，Bzlmod 采用了更宽松的 SemVer 规范。不同之处包括：
- 根据 SemVer 的规定，版本中的“发布”部分必须包含 3 个段：
MAJOR.MINOR.PATCH。在 Bazel 中，此要求放宽了，允许任意数量的段。 - 在 SemVer 中，“发布”部分中的每个段都必须仅包含数字。在 Bazel 中，此限制放宽为允许使用字母，并且比较语义与“预发布”部分中的“标识符”相匹配。
- 此外，系统不会强制执行主要版本、次要版本和补丁版本递增的语义。不过，如需详细了解我们如何表示向后兼容性，请参阅兼容性级别。
任何有效的 SemVer 版本都是有效的 Bazel 模块版本。此外，两个 SemVer 版本 a 和 b 比较结果为 a < b 当且仅当它们作为 Bazel 模块版本进行比较时结果也为 a < b。
版本选择
考虑一下版本化依赖项管理领域中的一个常见问题，即菱形依赖项问题。假设您有以下依赖关系图：
A 1.0
/ \
B 1.0 C 1.1
| |
D 1.0 D 1.1
应使用哪个版本的 D？为了解决此问题，Bzlmod 使用 Go 模块系统中引入的最小版本选择 (MVS) 算法。MVS 假设模块的所有新版本都向后兼容，因此会选择任何依赖项（在本例中为 D 1.1）指定的最高版本。之所以称为“最小”，是因为 D 1.1 是满足我们要求的最早版本 - 即使存在 D 1.2 或更新版本，我们也不会选择它们。使用 MVS 可创建高保真且可重现的版本选择流程。
已撤消的版本
如果某些版本应避免使用（例如存在安全漏洞），注册表可以将其声明为已撤消。当选择已撤消的模块版本时，Bazel 会抛出错误。如需修复此错误，请升级到较新的非撤消版本，或使用 --allow_yanked_versions 标志明确允许使用撤消的版本。
兼容性级别
在 Go 中，MVS 关于向后兼容性的假设之所以有效，是因为它将模块的向后不兼容版本视为单独的模块。就 SemVer 而言，这意味着 A 1.x 和 A 2.x 被视为不同的模块，并且可以共存于已解析的依赖关系图中。这得益于在 Go 中将主要版本编码到软件包路径中，因此不会出现任何编译时或链接时冲突。
不过，Bazel 无法提供此类保证，因此需要“主要版本”号才能检测到向后不兼容的版本。此数字称为兼容性级别，由每个模块版本在其 module() 指令中指定。有了这些信息，当 Bazel 检测到已解析的依赖项关系图中存在兼容性级别不同的同一模块的版本时，便会抛出错误。
覆盖对象
在 MODULE.bazel 文件中指定替换项，以更改 Bazel 模块解析的行为。只有根模块的替换项会生效，如果某个模块用作依赖项，则其替换项会被忽略。
每项替换都针对特定模块名称指定，会影响依赖关系图中的所有版本。虽然只有根模块的替换项会生效，但它们可以用于根模块不直接依赖的传递性依赖项。
单版本替换
single_version_override 有多种用途：
- 借助
version属性，您可以将依赖项固定到特定版本，无论依赖项图中请求的是哪个版本的依赖项。 - 借助
registry属性，您可以强制此依赖项来自特定注册表，而不是遵循正常的注册表选择流程。 - 借助
patch*属性，您可以指定要应用于下载模块的一组补丁。
这些属性都是可选的，可以相互搭配使用。
多版本替换
可以指定 multiple_version_override，以允许同一模块的多个版本在解析的依赖关系图中共存。
您可以为模块指定一个明确的允许版本列表，这些版本必须全部出现在解析前的依赖关系图中 - 必须存在依赖于每个允许版本的某些传递依赖项。解决冲突后，只会保留模块的允许版本，而 Bazel 会将模块的其他版本升级到同一兼容性级别中最近的更高允许版本。如果不存在相同兼容性级别且更高的允许版本，Bazel 会抛出错误。
例如，如果版本 1.1、1.3、1.5、1.7 和 2.0 在解析前的依赖关系图中存在，并且主要版本是兼容性级别，则：
- 如果多个版本替换项允许
1.3、1.7和2.0，则1.1会升级到1.3，1.5会升级到1.7，其他版本保持不变。 - 如果多个版本替换允许
1.5和2.0，则会导致错误，因为1.7没有相同兼容性级别的更高版本可供升级。 - 允许多个版本替换的
1.9和2.0会导致错误，因为在解析之前，依赖关系图中不存在1.9。
此外，用户还可以使用 registry 属性替换注册表，这与单版本替换类似。
非注册替换项
非注册表替换会从版本解析中完全移除模块。Bazel 不会从注册表中请求这些 MODULE.bazel 文件，而是从代码库本身请求。
Bazel 支持以下非注册表替换：
定义不表示 Bazel 模块的仓库
借助 bazel_dep，您可以定义表示其他 Bazel 模块的代码库。
有时，我们需要定义一个不表示 Bazel 模块的仓库；例如，一个包含要读取为数据的纯 JSON 文件的仓库。
在这种情况下，您可以使用 use_repo_rule 指令通过调用 repo 规则直接定义 repo。此代码库仅对定义它的模块可见。
在底层，这是使用与模块扩展程序相同的机制实现的，可让您更灵活地定义代码库。
代码库名称和严格依赖项
支持模块的仓库的显式名称默认为其模块名称，除非 bazel_dep 指令的 repo_name 属性另有规定。请注意，这意味着模块只能找到其直接依赖项。这有助于防止因传递依赖项发生变化而导致意外中断。
支持模块的代码库的规范名称为 module_name~version（例如 bazel_skylib~1.0.3）或 module_name~（例如 bazel_features~），具体取决于整个依赖关系图中是否存在模块的多个版本（请参阅 multiple_version_override）。请注意，规范名称格式不是您应该依赖的 API，并且随时可能会发生变化。请勿对规范名称进行硬编码，而是使用受支持的方式直接从 Bazel 获取该名称：
* 在 BUILD 和 .bzl 文件中，对从代码库的显示名称（例如，Label.repo_nameLabelLabel("@bazel_skylib").repo_name。
* 在查找 runfile 时，请使用 $(rlocationpath ...) 或 @bazel_tools//tools/{bash,cpp,java}/runfiles 中的某个 runfile 库，或者对于规则集 rules_foo，使用 @rules_foo//foo/runfiles 中的某个 runfile 库。
* 从 IDE 或语言服务器等外部工具与 Bazel 互动时，请使用 bazel mod dump_repo_mapping 命令获取给定的一组代码库从表观名称到规范名称的映射。
模块扩展程序还可以将其他代码库引入模块的可见范围。