inclusive-dev-tools / woke

✊ Detect non-inclusive language in your source code.
https://medium.com/@caitlinelfring/woke-437880c3de64
MIT License
0 stars 0 forks source link

Add support for rule categories and ability to exclude categories in config #26

Closed jeremydelacruz closed 3 years ago

jeremydelacruz commented 3 years ago

Please check if the PR fulfills these requirements

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...) Feature

What is the current behavior? (You can also link to an open issue here) Link to issue: https://github.com/inclusive-dev-tools/woke/issues/2 Rule definitions currently have no option for assigning and filtering on categories in the config file schema

What is the new behavior (if this is a feature change)? Rule definitions are able to specify optional string categories under the options field in the config file. Users are also able to exclude any number of categories with the new exclude_categories top-level yaml field.

# in this example, both rule1 and rule2 are excluded
exclude_categories:
  - cat1
  - cat2

rules:
  - name: rule1
    terms:
      - rule1
    alternatives:
      - alt-rule1
    severity: warning
    options:
      categories:
        - cat1

  - name: rule2
    terms:
      - rule2
      - rule-2
    alternatives:
      - alt-rule2
      - alt-rule-2
    options:
      categories:
        - cat1
        - cat2

  - name: rule3
    terms:
      - rule3
      - rule-3
    alternatives:
      - alt-rule3
      - alt-rule-3

A given rule is able to be assigned any number of categories and a given category is able to be assigned to any number of rules. When a category is "excluded", all rules that contain that category are removed from the enabled ruleset during the rules configuration step.

Does this PR introduce a breaking change? (What changes might users need to make due to this PR?) No breaking changes, categories are totally optional and backwards compatible

Other information:

jeremydelacruz commented 3 years ago

Something to note, I see no merge conflicts with the fork's main branch, but saw a potential merge conflict alert when pointed to the original repo -- do we need to fast-forward our main branch again?