Xùdōng Yáng

- Ability to "call" module rules in MODULE.bazel - Loading and executing the `module_rule_exports` file of any referenced Bazel modules, after `bazel_dep`s are resolved (i.e. post-discovery-and-selection) - Running the resolve...

- [ ] Patches in index registries (source.json) - [ ] Patches in overrides (archive, git, single_version) - [ ] Fuzzy matching The plumbing of patching information is already done...

Either as an override, or as a single-module registry.

- [ ] git_override - [ ] single module registries Both need the Git fetcher to be implemented first.

Currently we correctly parse and store this override, but don't use it properly. Changes need to be made in Selection.

Right now bzlmod doesn't deal with concurrent calls very well. All sorts of race conditions could happen if `bzlmod resolve` and `bzlmod fetch` are called concurrently, whether inside the same...

Reintroduce `dev_dependency` to `bazel_dep`. We removed it because of potential BUILD breaks in situations like https://github.com/bazelbuild/bazel/issues/12835. However, not having dev dependencies means that the dependency graph could be cluttered in...

- [ ] `bzlmod add [email protected]` - [ ] `bzlmod add -f [email protected]` - [ ] `bzlmod add X` - [ ] `bzlmod add --upgrade_all` - [ ] `bzlmod remove...

Retaining `Postable`s across the graph increases the memory usage of every dependent Skyframe node. `ModuleExtensionResolutionEvent` is replaced with a lookup of the "done" Skyframe nodes for extension evaluation in `BazelLockFileModule#afterCommand`....

The changes to the Maven deps specification got lost in a merge conflict resolution of 5e63f2d. Closes #22145. PiperOrigin-RevId: 629135777 Change-Id: I15e58ead4148b2e2ca677342aafbfe2694c78b1d