Skip to content

Allow users to specify custom linting rules #20

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
5 tasks done
bvobart opened this issue Jun 21, 2021 · 0 comments · Fixed by #25
Closed
5 tasks done

Allow users to specify custom linting rules #20

bvobart opened this issue Jun 21, 2021 · 0 comments · Fixed by #25
Assignees

Comments

@bvobart
Copy link
Owner

bvobart commented Jun 21, 2021

Let's face it, neither I, nor all developers who will ever work on this project, won't have the time to implement linting rules for every single tool under the sun. Also, for closed source tools or business-specific practice enforcement, users may want to build their own custom checks to enforce on their projects through mllint configurations.

The api.Linter interface is only three methods (Name, Rules and LintProject), which all return serialisable data, so it should be pretty easy to allow a user to define a custom linter in the mllint config, with a simple console command for LintProject. This will then provide the project details (and possibly mllint config?) to the command via stdin. The command is then expected to print a YAML or JSON linter result to the standard output. This linter result consists of what LintProject usually returns, i.e. a report and an error if there was any.

What is probably easier to configure though, is to have each custom rule define a script to lint it, which must then only return YAML or JSON score and details (e.g. { score: 100, details: "" }). Any non-YAML or JSON output is interpreted as an error, obviously automatically failing the rule. Having a linter that checks a single rule is different from api.Linter in mllint, as that may (and often should) check multiple rules in one run. However, this is probably easier to define.

Idea for how it will look in the config:

rules:
  custom:
    - name: Project complies to custom rule 1
      slug: custom/rule-1
      details: |
        Go all out with a full `markdown` description of this rule, what it checks, why it's there and how to implement it for a project.
        Multiline too.
      weight: 1 # importance within the Custom category of rules.
      run: python check_project.py # can be any command that can be passed to Golang's `os/exec`

To implement it all:

  • Determine and implement proper config structure for implementing custom linter
  • Create a Custom (custom) category and implement a linter to run all these custom linting rules and aggregate the results.
  • Test this custom linter runner linter runner linter thing.
  • Display the output of these custom linters in the report nicely.
  • Write some documentation and perhaps some examples as to how users should set up these custom rules.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant