Include JSON data from workspace/bundle in the linter and the language server

[anderseknert]

Regal currently looks only for *.rego files in the directory/directories provided (regal lint). or the workspace (regal language-server). This makes sense, as it's Rego we're working with. Some nice features however require us to consider including data from the directories read as well, similar to how OPA operates:

• Linter: rules like unresolved-import will currently flag paths that are provided as JSON data, as it's unaware of of those. Other rules could potentially benefit from knowledge about the data included too. A future unresolved-reference rule would be another example.
• LSP: Completion suggestions on data paths
• LSP: Eval via Code Lens / Execute Command, which might not work reliably in projects that rely on data being included

In order to avoid having unrelated data getting included, it would make sense to follow the model that the OPA VS Code extension uses, and just assume the workspace is a bundle. When treated as such, only data.json and data.yaml files will be included, and they will placed in the data tree based on their location (i.e. based on directory structure). I think this may pose a challenge though, as projects often have a "bundle directory" which should be used as the root rather than the top level project root. I guess we could provide a configuration option that allowed defining the path of a bundle (or bundles?), just like how the OPA VS Code extension does. But what that would actually mean is something we'd need to think about. Should multiple bundle directories be linted individually? And what does that mean for the LSP, which so far has been treating the workspace as it's "bundle"?

[anderseknert]

Thinking more about it now. Even if we have multiple bundles defined in a directory/workspace, we can't assume that they are isolated components. One bundle may very well depend on rules and functions in another. I think we just have to let OPA do the bundle loading and have things resolved the same way.

[anderseknert]

Just realized that we could check for .manifest files to detect bundle "root" directories and use those instead of configuration options. I guess technically a bundle directory doesn't need to have a .manifest file, but it's certainly a good practice, and required if more than one directory should be considered a bundle (or else they'll both try to own all paths).

I think a first implementation could use this method only, and then we can see how far that'll take us.

[nikpivkin]

Hi @anderseknert !

Is adding completion for inputs based on the passed schema being considered? Is it worth creating a separate issue for this?

[charlieegan3]

We have this issue here for input: https://github.com/StyraInc/regal/issues/725, there is also https://github.com/StyraInc/regal/issues/712 which is related too!

This would be a really nice feature to have for completions.

[anderseknert]

Indeed! Schemas, if present, should have highest precedence for completions, as they are the source of truth also for the compiler. If no schemas are found, we'd look for an input.json file for hints.