-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lsp: Add code lens support for evaluating rules #968
Conversation
- This is currently limited to VS Code clients, but may be extended to other clients too in the furure, if they can support it on their side. - Implementation wil recursively look for an `input.json` file and pick the one closest to the file evaluated, down to the level of the workspace root (if any file is found). Signed-off-by: Anders Eknert <anders@styra.com>
"github.com/styrainc/regal/pkg/builtins" | ||
) | ||
|
||
func (l *LanguageServer) Eval(ctx context.Context, query string, input string) (rego.ResultSet, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason that the input is a string rather than an io.Reader/[]byte/any?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, just was the easy choice I guess, but I can look into changing that in the next PR 👍
|
||
responseResult := map[string]any{} | ||
|
||
err = l.conn.Call(ctx, "regal/showEvalResult", responseParams, &responseResult) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We must use a custom event here as there is client code that will actually show this - rather than being in a generic message/location? Just checking I have that right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly! Client side code over here.
// purely by the LSP. Clients that are capable of handling the code lens callback | ||
// should be added here though. | ||
if l.clientIdentifier == clients.IdentifierVSCode { | ||
initializeResult.Capabilities.CodeLensProvider = &types.CodeLensOptions{} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps to come later, but something we can write to an result.json instead perhaps, but still show the command. (as discussed)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, that'll come next!
- This is currently limited to VS Code clients, but may be extended to other clients too in the furure, if they can support it on their side. - Implementation wil recursively look for an `input.json` file and pick the one closest to the file evaluated, down to the level of the workspace root (if any file is found). Signed-off-by: Anders Eknert <anders@styra.com>
This is currently limited to VS Code clients, but may be extended to other clients too in the furure, if they can support it on their side.
Implementation wil recursively look for an
input.json
file and pick the one closest to the file evaluated, down to the level of the workspace root (if any file is found).