The root of the Bazel workspace is indicated by the MODULE.bazel file.
https://bazel.build/external/module describes a Module as “a Bazel project that can have multiple versions, each of which publishes metadata about other modules that it depends on”. This is similar to most programming languages which use a well-known file to declare a package and its dependencies.
Some tools still rely on the older WORKSPACE or WORKSPACE.bazel file to appear in the workspace root, such as bazel-watcher. As a workaround, leave an empty file at this path with a comment explaining why it still exists.
Bazel hosts a “Central Registry” of third-party modules that extend Bazel’s abilities or provide build instructions for libraries. These may be browsed at https://registry.bazel.build.
Since you selected “Shell (Bash)” as a language, you see a dependency on that module, which provides the plugin (”rules”) for shell scripts:
# Depend on a specific version of a module from the registry
# (https://registry.bazel.build/modules/rules_shell)
bazel_dep(name = "rules_shell", version = "0.3.0")“Nested” modules are possible, but discouraged. The rest of the training assumes that a Bazel module is one-to-one with a git repository. Also, as this is a typical monorepo project, this module is a “leaf” - nothing else depends on it. So you don’t need to publish it anywhere.
If more setup is required for the rules, that appears in MODULE.bazel as well. For example, this is where you could refer to some third-party packages used in the language. Later 100-series courses will show how to interact with language-specific package managers.
