vscode-bazel
vscode-bazel copied to clipboard
bazelbuild
Implement language server for Starlark
First off, I'm really excited to see the Bazel team creating a repository for vscode support and I would love to contribute to it!
Secondly, Is this Repository going to be developing a Language Server Protocol implementation? Seems like it could be a great opportunity to develop a resource that could be reused in other editors as well.
Inside Google, we have an implementation of LSP in progress (with completion, jump to definition, and diagnostics). The bad news is that it relies on an internal framework. I expect it to be open-sourced early 2019, but I have little control on that.
I created this repository to publish a debugger (to execute bzl files step by step and observe variables), I hope it will be added soon. And I'd like this repository to replace https://github.com/devoncarew/bazel-code (from @devoncarew) to have everything in one place.
Thanks for the info! I'll look forward to that release in 2019 and it also sounds good to have everything in one place. Does this plan on bringing in things from https://github.com/dprogm/vscode-bazel-tools (from @dprogm) as well? That extension seems more focused on running bazel tasks.
And I'd like this repository to replace https://github.com/devoncarew/bazel-code (from @devoncarew)
👍
If @dprogm is willing to contribute, that'd be great too!
(I can give write access if someone wants to help maintaining the repository)
I also like the idea of having all bazel related vscode plugins in one place. So I would definitely join and contribute.
@laurentlb is that progress published somewhere? Or if was announced in a roadmap? It would be really exciting to see a starlark LSP for vscode :)
No, sorry. There's some code at Google that I hoped would get open-sourced. It's unfortunately not happening.
If someone wants to work on a LSP implementation, I'll be happy to provide some guidance.
@laurentlb How significant is that internal framework? Is it possible to open source without it and then pile down on re-implementing the missing pieces? Or is forking a Python LS a better option (like https://marketplace.visualstudio.com/items?itemName=phgn.vscode-starlark seems have done?
Hey everyone! I have a team working on creating an LSP implementation for Bazel. Our project is a fork of this repo, we are working off of the develop branch, source code here. @laurentlb I've reached out to you on this issue before (apologies for all the pings), but we got little traction.
We're creating an implementation of a Bazel language server using Java. Why we're using java is outlined here. As it stands, our language server currently provides local path completion for deps and minimal syntax highlighting. We are currently working to expand our feature set to intelligently integrate with bazel. Our goal is to provide
- Intelligent autocompletion of
srcsfor any rule - Intelligent autocompletion of
depsfor any rule, whether those deps be from the local WORKSPACE or and external WORKSPACE - Intelligent autocompletion of any other attribute for any other rule, assuming those attributes are listed on this page from bazel docs
- Semantic highlighting to underline issues with invalid deps, srcs, rule names, load statements, etc
- Ability to navigate from a src file to its associated BUILD file
That's the MVP of what we hope to provide. I'm posting here and hoping to get some guidance on how to overcome some issues we're running into. The biggest question we have right now is:
We believe that we need to evaluate starlark source in order to interpret which Bazel rules are valid as well as which attributes on a particular bazel rule are valid. We are thinking that our language server should analyze the WORKSPACE file for any given project and evaluate the starlark code to determine which rules are valid as well as their API. This will allow us to provide autocompletion/semantic highlighting for all BUILD files in any project. The issue here is that this code is locked down in the bazel repository.
We are trying to avoid mimicking/mocking the behavior Bazel, we would much rather hook into what already exists. We would really appreciate any feedback or ideas on how to deal with this. Thanks for any help.
Edit: Here is a better visualization of the problem we're trying to solve:
Joining the chorus of folks who would love this, subscribing, and maybe helping connect a few useful dots.
@josiahsrc, any updates on how things are going? Not sure if you ever heard back from @laurentlb. Looks like ownership was passed off to @philwo and @coeuvre (who'll be back shortly after GitHub mysteriously pulled his profile) in #248.
Maybe one of them can help you get updates/contact on the effort inside google? Esp given this is the first, and seemingly most-wanted request? Seems like people here are pretty excited. Wonder if Google would be willing to release parts of theirs for use, open source or not. There might also be some goodies in the IntelliJ plugin, which has great BUILD autocomplete, IIRC.
And @laurentlb, I see elsewhere on the interwebs that you're working on building a new IDE for Google? Anything we vscode-bazelers should know about the efforts there?
[Normally I'd roll up my sleeves on this one, but I should stay focused on solving the autocomplete-in-source issue (#179 w/ bazel-compile-commands-extractor) esp since I also have a startup I need to focus on.]
Hi @cpsauer 👋
We took the bazel language server as far as we had band-width for. Ultimately, we had to drop it due to 1) our capstone course ending (which was the reason we originally started building it) and 2) there not being enough support behind it. After capstone, I took the liberty of making some last minute changes to get the language server into a usable state. The source code for that is on this branch which has the features listed in this presentation. I can't guarantee that this LS implementation has held up over a year, but I'm happy to distribute a VSIX file for anyone interested in trying it out.
Having said that and having built a prototype for a Bazel LS, I have a much more clear idea of how to go about building a stable LS for Bazel. I don't have the resources at the moment to build out a stable LS alone, but I would be happy to contribute/consult on a group project for implementing an LS for Bazel provided there enough of a need for it and enough support from inside google.
Wow, that was fast! Thanks for the update! Hadn't realize it was a capstone project, but it makes me smile that you sought out such a real issue and went after it.
The presentation videos are super great. I mean, I'd love a version of this plugin that could do all that :)
I guess the question is: Based on your learnings, do you think it'd need rebuilding to be useful to people longer term, going forward?
Hopefully we'll also hear back on the google efforts and figure out a good way to move forward
I uploaded a VSIX compression of the LS here. Again, there's no guarantee on stability, but it may be somewhat helpful. As a note, the server might get stuck or become out of sync with what's in memory. In such cases you can use these commands to restart or sync the server.
For stability, yes. Our LS used the java implementation of the Starlark parser which was taken directly from the main Bazel repo. This implementation has since drifted from how we use it in the LS. Long term, it would be wisest to use the golang implementation, which promises a more stable API.
Heh, spectacular! Awesome to get label autocompletion--and to get fast feedback when targets have been typed wrong. Love the logo, too :) Thank you, and go BYU!
Reuploading to GitHub, rather than hammering Josiah's google drive: vscode-byubazel-1.1.5.vsix.zip
Install this with:
wget https://github.com/bazelbuild/vscode-bazel/files/8046189/vscode-byubazel-1.1.5.vsix.zip
unzip vscode-byubazel-1.1.5.vsix.zip
code --install-extension vscode-byubazel-1.1.5.vsix.zip
rm vscode-byubazel-1.1.5.vsix*
# And also install the normal Bazel extension to get, e.g., Buildifier info. Seems to be broken in the modded one
code --install-extension BazelBuild.vscode-bazel
Notes for others, after playing with it for a bit:
This is a great stopgap, but it'd still be really great to have an official, ongoing effort, perhaps out of Google. Hopefully we'll at least hear from Google!
Key features I'm seeing in Josiah's fork but not this one, that I've found most useful so far:
- Detection of invalid labels in
srcsanddepsattributes, including in custom rules (but not in all labels, and not working when the Bazel workspace root differs from the vscode project root). - Auto-completion after the ":"
- Jump to target definition
Key features that would be great to add:
- Auto-completion after "//' "@" for rooted or package paths.
- The latter doesn't currently happen at all, and the former is currently dependent on the project root being the same as the workspace root.
- More generally, support for Bazel WORKSPACEs not rooted at the same place as the vscode project root
- Checking of anything with the key attributes of a label. (Starts with @ or // or : or ends with a file extension--or something more sophisticated by looking at the rule definition)
- Quick pull-up of documentation for attributes. (The stack build extension has this, but misses the other more important features)
You might also see an error like the following in the Bazel Language Server output and be alarmed, but it seems to recover fine--and still be mighty useful
[Fatal Error] log4j2.xml:21:6: The processing instruction target matching "[xX][mM][lL]" is not allowed.
...
at server.BazelLanguageServer.<clinit>(BazelLanguageServer.java:17)
It appears facebook have a starlark language server for buck2 (https://github.com/facebookexperimental/starlark-rust). Maybe this could be of use?
It appears facebook have a starlark language server for buck2 (https://github.com/facebookexperimental/starlark-rust). Maybe this could be of use?
Linking to https://github.com/facebookexperimental/starlark-rust/pull/51 for potentially relevant context.
There appears to be an implementation of the language server for bazel in starlark-rust. See https://github.com/facebookexperimental/starlark-rust/blob/main/starlark_bin/bin/bazel.rs
I created a simple vscode extension to register it as a language server for starlark files and it seems to work reasonably for go to definition in load statements & label autocomplete. There's a few obvious bugs, but it seems like a great start. Since it says it is only temporary and marked for deletion, maybe we could extract it into a bazel-owned repo and add experimental support for it in this extension.
FYI https://github.com/facebookexperimental/starlark-rust/blob/main/vscode/README.md is the unpublished VSCode extension frontend that is already well integrated with the starlark binary.
I saw that after creating my own extension, but it doesn't really do much except launch a language server: https://github.com/facebookexperimental/starlark-rust/blob/main/vscode/client/src/extension.ts
I think there's still use for integrating the LSP into a bazel-specific extension.
Came across this thread and I wanted to share an implementation of a Starlark LSP I've been working on to learn Rust! I decided to pick this up after realizing that the LSP included with starlark-rust didn't yet support things like type inference, auto-complete for fields/methods, etc.
It's still in a pretty rough WIP state but can handle things like rudimentary type inference/error diagnostics + auto-complete for method on builtin types within a single file. I do plan on spending a good amount of my free time working on this; my plan is to implement the core Starlark spec first, and then start supporting Bazel-specific features (e.g. auto-complete/type inference for Bazel builtins, auto-complete/navigation for labels, etc.)
The Bazel LSP in the starlark-rust repo never intended to be supported long-term, and as a result are slow in accepting PRs for it.
Therefore I've forked this work and extended it here: https://github.com/cameron-martin/bazel-lsp
@cameron-martin I think https://github.com/bazelbuild/vscode-bazel/pull/317 doesn't fully address this issue. It opens a client to work with an existing Starlark LSP which lacks support for Bazel files.
Per https://github.com/facebookexperimental/starlark-rust/issues/104#issuecomment-1900153760, should we keep this issue open until we have a path forward for a more official LSP for Bazel?
Good point, I guess it makes sense to keep this issue open until there's a mature LSP available.
I will say, the BYU one (above) has served us very well! Maybe there's a way to merge it in?
On the topic of having a Bazel-first LSP, something that I've been getting to work in my implementation, and something that could potentially be managed through this extension, is using the ApiExporter, which dumps a protobuf file of all Bazel builtin functions/types with this schema.
Combined with some sort of mechanism for supplying type information (e.g. for function parameters), it turns out this works pretty well for enabling features like type-inference + autocomplete + documentation hovers for not just rules but also common objects like ctx, and lets us get much closer to a "typical" IDE experience for writing Bazel rules. For example, here's an example of the starpls LSP providing autocompletions on ctx while writing a simple rule implementation function, with type annotations specified via PEP 484-style type comments:
One thing I've been thinking about is how to distribute these proto files (each of which are bout around 500KB in size) for different versions of Bazel. Maybe they could be bundled with the vscode-bazel .vsix and exposed to an LSP implementation via some standard environment variable? It would also be pretty cool for the extension to let users supply their own protos via some configuration option and get autocomplete for other projects that use Starlark, e.g. Tilt's Tiltfiles.