A matter of Facts, and why you should check in your MODULE.bazel.lock

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.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.