rules_lint

The rules_lint ruleset integrates linting and formatting as first-class concepts under Bazel. It is designed to work with your existing Bazel rules and BUILD files without requiring changes to them. Instead of adding lint wrapper macros, you simply lint your existing *_library targets.

Key features include:

• Incremental: Lint checks and fixes run as normal Bazel actions, supporting Remote Execution and Remote Caching.
• Water Leak Principle: You can lint only changed files, allowing you to start linting new changes even in repositories with many existing issues.
• Formatting: Can format files not known to Bazel (like shell scripts) by running directly on the file tree.
• Configuration: Honors the same configuration files used by these tools outside of Bazel (e.g., in your editor).

The following tools are supported for Python code within the rules_lint ecosystem:

Formatters

• Ruff: A fast Python linter and formatter.

Linters

• Ruff: Fast Python linter for catching various issues.
• Pylint: Comprehensive Python linter.
• Flake8: Style guide enforcement.
• Pydoclint: Checks for docstring and signature consistency.
• Ty: Type checker.

This configuration uses the following tools for QML files, both of which are invoked via PySide wrappers:

• Formatter: qmlformat (Qt's formatter for QML files).
• Linter: qmllint (Qt's linter for QML files).

In this example, the qml tag is used to identify these tools for both formatting and linting tasks.

The Rust example supports the following tools:

Formatters

• rustfmt: The official Rust code formatter.

Linters

• Clippy: The standard Rust linter used to catch common mistakes and improve code quality.

The rules_lint ecosystem supports formatting for several specialized languages using a variety of underlying tools. This example demonstrates how to handle formats that do not have dedicated standalone examples in the repository.

Supported Formats and Tools:

• CUE: Formatted with cue fmt.
• Gherkin: Formatted with Prettier + a Gherkin plugin.
• GraphQL: Formatted with Prettier.
• Jsonnet: Formatted with jsonnetfmt.
• HTML Jinja: Formatted with djlint.
• JSON5: Formatted with Prettier.

When using ktlint, you can manage violations and styling using the following files:

• ktlint-baseline.xml: Use this baseline file to suppress known existing violations so you can focus on new code.
• .editorconfig: ktlint respects standard .editorconfig files for code style configuration.

The behavior for ignoring files differs between linters and formatters:

• Linters: Only visit files that are explicitly part of the Bazel dependency graph (i.e., files listed in the srcs attribute of a target).
• Formatters: Honor .gitignore and .gitattributes files. You can also use tool-specific ignore files, such as .prettierignore for Prettier.

Note on non-standard syntax: If you have files with extensions that don't match their content (e.g., a YAML template named my-template.yaml that contains non-YAML interpolation), it is recommended to change the file extension (e.g., my-template.yaml.tmpl) rather than trying to ignore it.