Skip to content

v0.12.0

Compare
Choose a tag to compare
@github-actions github-actions released this 09 Nov 08:44
· 607 commits to main since this release
b772b0a

This release adds a long-awaited capabilities feature to Regal. v0.12.0 also brings four new linter rules, and the usual improvements and fixes.

Capabilities

It is now possible to tell Regal which version of OPA (or other project built on top of OPA!) you are targeting. This will have Regal take into account things like which built-in functions are available for the given version, but also more advanced features that may have been introduced in later versions. Relevant linter rules have been updated to support this feature. To provide an example, the custom-has-key-construct rule, which recommends replacing custom "has key" implementation with in and object.keys will now only run if the targeted OPA version is v0.47.0 or later, as that is when object.keys function was introduced.

For more information, see the docs on configuration.

New rule: inconsistent-args

Category: bugs

Inconsistent naming and placement of function arguments is bound to lead to bugs, and should be avoided. The new inconsistent-args will help you spot these inconsistencies and fix them.

Avoid

find_vars(rule, node) if node in rule

# Order of arguments changed, or at least it looks like it
find_vars(node, rule) if {
    walk(rule, [path, value])
    # ...
}

Prefer

find_vars(rule, node) if node in rule

find_vars(rule, node) if {
    walk(rule, [path, value])
    # ...
}

For more information, see the docs on inconsistent-args.

New rule: unnecessary-some

Category: style

Sometimes (some-times?) the some keyword is used in conjunction with in where only in would suffice:

Avoid

is_developer if some "developer" in input.user.roles

Prefer

is_developer if "developer" in input.user.roles

While the two expressions produce the same result, the some keyword is redundant here.

For more information, see the docs on unnecessary-some.

Thanks @kristiansvalland for suggesting this rule!

New rule: yoda-condition

Category: style

Yoda conditions — expressions where the constant portion of a comparison is placed on the left-hand side of the comparison — provide no benefits in Rego. They do however add a certain amount of cognitive overhead for most policy authors in the galaxy.

Avoid

allow if {
    "GET" == input.request.method
    "users" == input.request.path[0]
}

Prefer

allow if {
    input.request.method == "GET"
    input.request.path[0] == "users"
}

For more information, see the docs on yoda-condition.

New rule: one-liner-rule

Category: custom

The new one-liner-rule linter rule will help inform you of any rules that may be turned into one-liners using the new if construct for rules.

Avoid

is_admin if {
    "admin" in input.user.roles
}

Prefer

is_admin if "admin" in input.user.roles

Note that this isn't a general recommendation, but an optional custom rule, which must be enabled manually in the Regal configuration.

For more information, see the docs on one-liner-rule.

Ignore directives improvement

Ignore directives, i.e. comments that tell Regal to ignore one or more rules on a specific line of code, can now be placed on the same line as the violation(s) and not just above:

# regal ignore:prefer-some-in-iteration
name := ast.ref_to_string(ast.functions[i].head.ref)

# Can now also be expressed as

name := ast.ref_to_string(ast.functions[i].head.ref) # regal ignore:prefer-some-in-iteration

Other improvements

  • The identically-named-tests rule now gives a precise location for violations and not just the name of the file where it happened.
  • The prefer-set-or-object-rule now takes more simple array -> set conversion comprehension variants into account, and won't recommend converting those to rules.
  • Added count-comments config option to the rule-length rule, which allows you to configure whether comments should be counted towards the rule length limit (default: false).

Bugs fixed

Community

Changelog