Skip to content

[FR] Implement a configuration mapping for disabling rules on per-file basis #1511

@webknjaz

Description

@webknjaz

Prerequisites

  • Are you running the latest version of this application?
  • Have you checked the Frequently Asked Questions document?
  • Did you perform a cursory search of other issues to look for related issues?

Feature Request

Description

We're looking into the possibility of integrating this linter into pip-tools, but the inability to selectively disable certain rules by file path wildcards is blocking us right now.

It'd be good to support having a mapping in the config for listing rules to be disabled in certain parts of a folder layout, like other linters have.

For example, we'd need to disable MD041 for changelog.d/*.md and CHANGELOG.md; and MD024 (plus likely MD036) for CHANGELOG.md.

Fragment files under changelog.d/ have limited lifetime — they are added with each PR and deleted in bulk as a part of the release process. Forcing every contributor to add a rule suppression pragma into each fragment file in each PR seems unfair. Their contents end up in CHANGELOG.md through templating and have pre-defined list of category names that repeat as titles. Plus we wouldn't want those inline suppressions in the resulting file anyway.
Additionally, CHANGELOG.md gets included into a Sphinx document meaning that it shouldn't have an h1 title inside.

Quirks like are legitimate reasons for permanently set up rule exclusions in well-defined places in repos.

Desired Behavior of Feature

Given something like

per-file-ignores:
  'file/path-wildcard/*.md':
  - MDXXX
  - MDYYY
  - MDZZ
  - first-line-heading

I'd expect MDXXX and MDYYY rule violations to be suppressed in files like file/path-wildcard/doc.md. Additionally, rules starting with MDZZ would be suppressed as well (that'd be MDZZ0, MDZZ3 etc) — it is a pretty common practice to do prefix-matched rule group suppressions. Aliases like first-line-heading should behave as an exact match.

What Are the Benefits of This Feature?

This is a pretty popular convention in the ecosystem linters.
For example, flake8 has per-file-ignores and Ruff has lint.per-file-ignores to allow suppressing certain rules in certain parts of the project under linting.
Here's how I use the respective feature with those linters, for example: https://github.com/cherrypy/cheroot/blob/a47550029a10d68eb3d4c1630f40040c8bd3a52f/.flake8#L96-L154 / https://github.com/cherrypy/cheroot/blob/a47550029a10d68eb3d4c1630f40040c8bd3a52f/.ruff.toml#L208-L219.

For code linters, it's useful when certain places have different rules (for example, tests often have intentional violations or differing conventions compared to the main runtime components; or sometimes adopting a new linter is difficult in existing codebases but they could be added in a way that they start checking any new modules while surgically excluding not-yet fixed files/folders/path patterns).

In case of checking text documents, the reasoning is similar. A popular example is files that are included/templated into other documents. Like when collecting changelog fragments managed by tools like Towncrier, such small snippets of markdown, while being in standalone files, would be expected not to have any titles and such — so the respective directory would disable the rule that demands titles.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions