August 2026 Summaries

Aspect has launched a public Bazel ecosystem statistics page that aggregates daily telemetry from repositories using its open-source rulesets, showing Bazel version adoption and dependency-version trends for Bazel Central Registry modules, with CI and non-CI activity separated. The data is intended to help ruleset maintainers make better-informed compatibility and deprecation decisions, though report counts reflect dependency graph evaluations rather than unique users or repositories and are weighted toward CI activity. Telemetry is collected by the open-source `aspect_tools_telemetry` module during bzlmod module-graph evaluations, generally not during routine builds and never for WORKSPACE-only builds, and it sends limited platform, Bazel, dependency, CI, and pseudonymous grouping information rather than source code, paths, URLs, or command lines. Users can permanently disable collection with the `DO_NOT_TRACK` setting, selectively exclude fields such as organization or dependencies, add a salt to hashes, or redirect reports to an internal collector. The underlying aggregated JSON dataset is publicly available but is not presented as a stable API, and other ruleset maintainers can adopt the telemetry module to obtain more direct insight into their own users’ version adoption.

Bazel’s Facts API, available in Bazel 8.5 and later, allows module extensions to save JSON-like metadata such as integrity hashes in MODULE.bazel.lock and reuse it on later evaluations without repeated network access. This enables toolchain rulesets to retain hardcoded hashes for common versions while supporting newly released, nightly, release-candidate, or custom versions through a three-stage process of checking bundled version tables, reading cached lockfile facts, and fetching metadata once when necessary. Rulesets including rules_go, rules_js, rules_swc, and rules_nodejs use this pattern to improve reproducibility, offline and air-gapped compatibility, and support for versions not yet included in a ruleset release, while maintaining backward compatibility through conditional Facts support. Extensions should cache only metadata actually used, validate cached data because facts can outlive implementation changes, and mark themselves reproducible only when all required hashes are resolved. The discussion emphasizes committing MODULE.bazel.lock and enforcing it in CI with --lockfile_mode=error, since a checked-in lockfile preserves resolved dependencies and fetched facts across fresh clones, protects against upstream changes or yanked modules, makes dependency updates reviewable, and avoids unnecessary remote lookups. Repositories testing multiple Bazel versions can designate one supported version to validate the committed lockfile while allowing other matrix jobs to regenerate it temporarily.