rego-v1: Future-proofing format pkg tests to be 1.0 compatible

[johanfylling]

No description provided.

[johanfylling]

Turns out, not allowing keywords in refs is an actual issue in v1, and not just a nuisance.

We can make the test.contains package parse by bracketing it: test["contains"].
This is however not only ugly for no actual benefit, but the formatter will actually output it as package test.contains, which won't parse 😞.

We could fix the formatter to output package test["contains"] instead. But I think we should instead allow refs to contain keywords.

[ashutosh-narkar]

But I think we should instead allow refs to contain keywords.

Was there a reason to not allow refs to contain keywords?

We could fix the formatter to output package test["contains"]

We could update the --rego-v1 flag to do that. But as you said we should allow refs unless there is a good reason not to do it.

[johanfylling]

I think the argument against allowing keywords in refs is that we don't allow such rule names, e.g.

package foo

if if { true } # error: 'if' is not a valid rule name

but we allow you to create an empty module:

package foo.if

which would generate an empty virtual document at data.foo.if. This creates a sort of parity mismatch, where we allow you to create data.foo.if one way, but not the other.

[anderseknert]

That can still be created via JSON data, so won't that mismatch always exist? The question is why you wouldn't be allowed to reference such data (without special handling / quoting) where it's impossible for it to clash with a keyword... i.e. input.package is obviously distinctly different from package alone.