Regal v0.33.0 released!

[anderseknert]

This release adds 4 new linter rules to Regal, alongside significant performance improvements and several bug fixes.

New Rule: in-wildcard-key

Using a wildcard variable (_) for the key in the key-value form of iteration (some _, value in collection) is never needed, and can be replaced by the simple some value in … form . This rule flags cases where the key iteration is redundant. (Read more)

package policy

allow if {
    # Avoid: key iteration ('_') is redundant if only 'user' is used
    some _, user in input.users
    # do something with each user
}

allow if {
    # Prefer: clearer intent when only iterating values
    some user in input.users
    # do something with each user
}

New Rule: confusing-alias

While import aliases can improve readability, aliasing an import reference that is also imported without an alias is confusing, as both names point to the same resource. This rule catches such cases. (Read more)

package policy

# Avoid: both 'users' and 'employees' point to data.resources.users
import data.resources.users
import data.resources.users as employees

# Prefer: a single import for any given resource
# import data.resources.users

New Rule: mixed-iteration

Rego supports different styles of collection iteration. While "reference style" iteration (collection[_]) can be concise for deeply nested structures, mixing it with the some .. in style within a single iteration expression makes for code that’s more difficult to follow. This rule encourages consistency within a single iteration statement. (Read more)

package policy

allow if {
    # mixing 'some .. in' and reference iteration
    some resource in input.assets[_]
    # do something with resource
}

allow if {
    # using 'some .. in' iteration consistently
    some asset in input.assets
    some resource in asset
    # do something with resource
}

New Rule: narrow-argument

This new rule analyzes function arguments to suggest narrowing them down to the minimal value the function depends on. This can improve clarity and reusability. The rule considers incrementally defined functions across all their definitions. This is a powerful but opinionated rule and is thus in the custom category and is not on by default. See the documentation for how to enable it if you’re curious to try it out! (Read more)

package policy

# Avoid: the function only uses the 'email' property of the 'user' object
valid_user(user) if endswith(user.email, "acmecorp.com")
valid_user(user) if endswith(user.email, "acmecorp.org")

# Prefer: narrowing the argument to only what the function needs
valid_email(email) if endswith(email, "acmecorp.com")
valid_email(email) if endswith(email, "acmecorp.org")

Performance Improvements

Several improvements have been made to reduce memory allocations and improve overall linting performance. Numbers below refer to Regal’s benchmark for linting its own policies.

• Optimized config loading and parsing, saving around 2.7 million allocations (#1491).
• Reduced allocations by approximately 2 million (#1494).
• Improved the performance of the use-strings-count rule, saving almost 1 million allocations (#1465).
• Optimized reference comparisons and small iteration patterns, saving around 300k allocations (#1472).
• Included performance enhancements alongside an update to the external-reference rule to make it more configurable (#1496).

OPA v1.3.0

Regal has been upgraded to use OPA v1.3.0. This brings several upstream improvements, including support for the new one-liner grouping in formatting (see OPA#6760). (#1459)

Bug Fixes

• Fixed a bug in the handling of Rego input from stdin. Thanks @tokyowizard for the report! (#1474)
• Fixed a panic that could occur in FindConfigRoots when supplied with unexpected arguments. (#1487)

Other Rule Updates

• The external-reference rule can now be configured with a maximum number of allowed external references, instead of solely flagging all external uses within a function. If you previously had this rule disabled, you might want to try enabling it now, and possibly tweak its configuration to your liking. (#1496)
• The rule-length rule now has a separate setting (max-test-rule-length) with a higher default value (60 vs 30) for test rules, acknowledging that tests often include substantial data. (#1476)
• Updated documentation for the rule-named-if rule based on community feedback received via the page feedback form (please let us know if you see issues! & thanks for the report!) (#1463)

Full changelog, and downloads, here.