#Vecode inc code

The extension would be written in TypeScript, because VS Code expects extensions to have a JavaScript entrypoint file that exposes hooks for VS Code to manage the extension's lifecycle.The language server would be a new crate, polar-language-server, to avoid concerning polar-core with LSP-specific code.

Also, the team knows Rust well, and it's generally our default for greenfield projects. The Polar interpreter is written in Rust, so writing the language server in Rust meant it would be easy to build on top of existing APIs in our Rust core. We wanted to write the language server in Rust.Designįor the initial design, we knew a few things: It would be a lot of duplicated effort to build N slight variations of the same feature set. Then, when we wanted to port the same functionality to IntelliJ, we'd have to figure out the corresponding APIs in IntelliJ, and the same for Vim, Emacs, and every other IDE. Every IDE that speaks LSP sends the same set of events across that bridge, like 'a document has been opened' or 'the user has requested all references for a particular symbol.' Every language server that speaks LSP can implement features like documentation-on-hover once and get that functionality across every LSP-fluent editor.īefore the Language Server Protocol, if we wanted to build a Polar language server to surface errors & warnings in VS Code, we'd use VSCode-specific APIs. Microsoft’s open-source Language Server Protocol abstracts a common set of IDE functionality across a JSON-RPC bridge. Limiting ourselves to those diagnostics improved the developer experience without giving us an endless list of features to implement. There's a lot of value in surfacing those issues to the developer ASAP. When writing Polar policies, these can be parsing errors (like 'you're missing a semicolon') or validation errors (like 'your policy references an unknown term'). For our initial foray we scoped it down to surfacing policy errors & warnings. There's a huge range of features that an IDE integration can provide, like auto-completion and jump-to-definition. We also knew we were going to want to fan out the functionality beyond VS Code in the future, and building on top of the Language Server Protocol (LSP) would minimize the work required to port the extension's functionality to Vim, IntelliJ, Emacs, and other editors. We restricted our initial focus to VS Code because we've had the most requests from our community for it. We expect our users to write Polar in a variety of environments, and there are a wide range of IDEs out there. If you’ve ever wanted to write an IDE extension for your language of choice, this post might be for you. In this post, we'll talk through our design decisions in building the extension, and along the way we'll touch on the Language Server Protocol and, more generally, how an IDE extension works. This shortens the development cycle for editing policies, giving you more time to spend on whatever sparks joy for you (and us more time to spend on making sure the kill orders issued by our sentient beta were a one-time glitch). While someday we’ll release a feature that lets a fully-sentient Oso write your authorization policy for you, in the interim we thought it would be a good idea to improve the developer experience of writing Polar policies.Īlong with Oso's 0.24 release, we shipped a VS Code extension that surfaces policy errors & warnings in VS Code instead of requiring you to run your application to see them. At the core of Oso is Polar, a declarative language for writing authorization policies. We build Oso, a batteries-included framework for building authorization in your application.

Vecode inc