Skip to main content
rules_lint, built and maintained by Aspect, runs linters and formatters as Bazel actions, so their results are cached and incremental like any other build output.

​
Why rules_lint

  • No changes needed to rulesets. Works with the Bazel rules you already use.
  • No changes needed to BUILD files. No lint wrapper macros, and lint doesn’t appear in bazel query output. Users lint their existing *_library targets.
  • Incremental. Lint checks (including producing fixes) run as normal Bazel actions, so they support remote execution and their outputs land in the remote cache.
  • Lint changes only. It’s fine if your repository has a lot of existing issues; you don’t need to fix or suppress them all to start linting new changes. We call this the “Water Leak Principle”: always fix the leak before mopping the spill.
  • Formats files Bazel doesn’t know about. Formatting runs directly on the file tree, so there’s no need to create targets for your shell scripts only to format them.
  • Honors your existing configuration files. The same config the tools use outside Bazel (for example, in your editor) applies under Bazel.

​
Supported tools

Formatters and linters ship for dozens of languages, including: See the full table in the repository; new tools are added frequently.

​
Running under the Aspect CLI

The aspect lint and aspect format tasks run rules_lint with hold-the-line linting that only fails on violations you introduced, and format only the files changed in your PR. Results post as status checks, review comments, and suggested fixes through the Aspect Workflows GitHub App or GitLab App, or surface as failing tests.

​
API reference

Per-linter configuration references live alongside each language: