-
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
Add source action to explore compiler stages #1096
Conversation
ad30ec0
to
949267d
Compare
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.
This is a really fun feature!
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.
Yay, this is a perfect new home for that code <3
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.
Some minor comments
cache *cache.Cache | ||
workspaceURI string | ||
client clients.Identifier | ||
baseURL string |
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.
I think this could be racy: we're setting the baseURL from a goroutine, but we retrieve it from GetBaseURL
. It's probably unlikely to be a problem in real world usage, since it involves user interactions, though. OTOH adding a mutex should be simple enough.
This PR integrates @srenatus excellent [opa-explorer](https://github.com/srenatus/opa-explorer/) with Regal, where we now start a web server along with the language server to host the explorer. Users will now see a "Source Action" in the context menu of any given Rego file, and when clicked will bring them to the explorer view for that file. Since a command for opening web pages client side is AFAIK only available in VS Code, this feature is sadly limited to that editor currently. Perhaps we can figure out some way to have the link show in Zed, similar to what we did for linter docs? For now, we're only loading a single file into the explorer for compilation. We could perhaps consider loading all modules in the workspace too, as otherwise compilation will always fail on e.g. unknown functions from outside the policy. Signed-off-by: Anders Eknert <anders@styra.com>
949267d
to
03ce353
Compare
This PR integrates @srenatus excellent [opa-explorer](https://github.com/srenatus/opa-explorer/) with Regal, where we now start a web server along with the language server to host the explorer. Users will now see a "Source Action" in the context menu of any given Rego file, and when clicked will bring them to the explorer view for that file. Since a command for opening web pages client side is AFAIK only available in VS Code, this feature is sadly limited to that editor currently. Perhaps we can figure out some way to have the link show in Zed, similar to what we did for linter docs? For now, we're only loading a single file into the explorer for compilation. We could perhaps consider loading all modules in the workspace too, as otherwise compilation will always fail on e.g. unknown functions from outside the policy. Signed-off-by: Anders Eknert <anders@styra.com>
This PR integrates @srenatus excellent opa-explorer with Regal, where we now start a web server along with the language server to host the explorer.
Users will now see a "Source Action" in the context menu of any given Rego file, and when clicked will bring them to the explorer view for that file.
Since a command for opening web pages client side is AFAIK only available in VS Code, this feature is sadly limited to that editor currently. Perhaps we can figure out some way to have the link show in Zed, similar to what we did for linter docs?
For now, we're only loading a single file into the explorer for compilation. We could perhaps consider loading all modules in the workspace too, as otherwise compilation will always fail on e.g. unknown functions from outside the policy.