October 2025 Summaries

Bazel employs a configuration language called Starlark, a Python dialect optimized for parallel evaluation to speed up builds, and necessitates linting and formatting like any programming language. Buildifier is a tool designed to format Bazel BUILD and .bzl files according to standard conventions, easing the process of maintaining code consistency and eliminating discussions around code formatting. Developers can install Buildifier in various ways, with pre-built binaries being a recommended option for convenience. To integrate Buildifier into development workflows, developers can use tools like direnv and bazel_env.bzl to manage the PATH, and configure editors like VSCode to run Buildifier automatically on file save. Additionally, setting up Aspect's rules_lint allows for a unified formatting setup across different languages, while pre-commit hooks ensure code is formatted before committing. Enforcing formatting consistency helps avoid unnecessary changes in pull requests. Buildifier's linting feature offers around 100 checks for Starlark files, primarily focused on Bazel's standard library, and it's recommended to implement these checks incrementally following the "Ratchet principle" to manage disruptions in the development process. The Aspect Workflows platform simplifies integrating Buildifier into CI systems by offering it as a task type, allowing for smoother setup and adherence to best practices.

Engineering often relies on tribal knowledge, where professionals adhere to familiar languages and technologies, influenced by their specific community's ideas and opinions. Bazel, a cross-language build tool, facilitates the exchange of ideas across these communities, advocating for the integration of older, stable technologies that form the foundation for many modern tools. The article highlights the mtree format, introduced in 4.3BSD-Reno in 1990, as a textual format that describes filesystem objects, useful for creating reproducible builds in systems like Bazel. The mtree format allows for the description of filesystem structures, permissions, and symlinks, making it valuable for composing tools and Docker images, with utilities like BSD tar offering reproducible archiving solutions. The piece underscores the importance of recognizing the value of older tools in solving contemporary problems, suggesting that often the best solutions are those that have long been established, rather than the latest technological trends.

Over the past year, there has been significant progress in generating and publishing API documentation for Bazel modules, particularly through the launch of a new system that centralizes and simplifies this process. Previously, documentation efforts were fragmented across various formats and platforms, leading to inefficiencies and contributor frustration. The new approach integrates documentation generation directly into the Bazel build system using a rule called `starlark_doc_extract`, allowing for seamless creation and publication of API docs alongside module releases in the Bazel Central Registry. This system leverages TypeScript and a Next.js application to render the documentation, avoiding the complexities and dependencies of Java implementations. Contributors are encouraged to enhance this process by updating rulesets to publish their documentation, improving existing documentation with additional examples, and suggesting usability improvements for the UI. The project is managed under the Rules Authors SIG by the Linux Foundation, inviting community participation and collaboration.