Closed cameron-martin closed 5 months ago
I'm going to review the patches when I get back to work tomorrow. My guess is these patches are fine, but that adding tests/bzlmod support is probably going too far? Curious what @stepancheg thinks, especially about the stable interface question.
My thoughts are to make the next steps (testing with Bazel, significant complexity) it's probably best to pull it out as a separate project. I don't think there's much value to leaving stale code in this repo as a test - we can just include a pointer to your code, and we do co-develop the LSP with the Buck2 usage of it, so it's not going to break. The interface is relatively stable, but it might be best to git submodule your Bazel LSP to avoid requiring releases if you do need to tweak the interface?
But keen to hear dissenting views, @stepancheg
I've pulled out the Bazel implementation here, where I am continuing any modifications: https://github.com/cameron-martin/bazel-lsp
Maybe in the future the bazelbuild org can inherit this.
I'll close this now, since bazel-lsp has advanced significantly past the bazel language server in this repo!
@cameron-martin bazel-lsp
readme is a bit misleading: it says "forked from starlark-rust", but it is actually just extends starlark-rust LSP for bazel. Up to you.
Also, I guess now we should remove Bazel support from starlark-rust repo and maybe point to bazel-lsp instead?
I wanted to attribute the original authoring of this bazel-specific extension of the language server to this repo, but yeah possibly a bit misleading...
Maybe saying "based on starlark-rust" is sufficiently vague to not be misleading?
I wanted to attribute the original authoring of this bazel-specific extension
This is not us, we accepted PRs, but we don't use Bazel. I think that was @MaartenStaa from digging git log.
I recently submitted a few patches to the Bazel LSP (#100, #101, #103). However, this is intended to be merely a proof of concept and there are some larger changes that need to be made (e.g. adding tests, bzlmod support). There was some discussion on the future of this project in #51, and the conclusion seemed to be to eventually split it out into a separate project and maintained by people with more of a stake in Bazel, but only when the interface is stable enough.