Rule: Add rule to avoid using implicit `true` when building an object (require explicit value)

[rplnt]

Summary

Add rule requiring explicit value (instead of relying on implicit true) when creating an object using the syntax foo[key] if {...}

Reasoning

In v1, this creates an object hello={"world":true}:

hello[input.message] if {
	input.message == "world"
}

While almost identical code in v0 created a set hello={"world"}:

hello[input.message] {
	input.message == "world"
}

Considering the amount of documentation/discussions available for v0 syntax it's easy to mistake these two. And even when ignoring that aspect, it's better for readability to have it explicitly written out as such:

hello[input.message] := true if {
	input.message == "world"
}

Notes

• There might be other instances where this rule (avoid implicit true) may apply, this was the one I stumbled upon
• Automatic fix should be possible see comment

[anderseknert]

Thank you for filing this!

I believe that's the only case where the implict assignment is confusing, and especially when moving between v0 and v1. We'll look into adding a rule to check for that before next release.

Automating a fix here is a little trickier, I think. Because we can't know if the user was trying to define a set the "old way" or the intention was to define an object. So perhaps best to just report it and let the user decide how to fix it? Obviously we'll cover both cases in the rule's documentation.

[anderseknert]

I've been pondering this for some time now, and while it can be confusing, this is a case where it's pretty much impossible to know if it's written this way by mistake or someone knows what they're doing. OPA just recently added support for parameterized tests, which uses this construct exactly. And we obviously can't flag all parameterized tests 😅

So my conclusion is this: if we want to have a rule to enforce this, it would have to be optional (i.e. the custom category). But any rule that is optional is also less likely to be discovered by someone new to Rego. So we're kinda between a rock and a hard place here. What do you think @rplnt?