kotlin-language-server
kotlin-language-server copied to clipboard
fwcd
Bazel support
If I understood the code correctly, KotlinLanguageServer keeps a single compiler instance which has a global view of sources and classpaths. That is, two independent kotlin/java modules will see symbols from each other as if they were part of the same module or classpath. Is this correct? Also, I'm guessing that the Koltin compiler instance is resource expensive. Right?
One possible approach is to add each Bazel target as a workspace root. In fact, that's the approach I invested some time so far.
Another approach avoid "symbol leak" by creating separated "Compilation Environments", one for each independent module (e.g. one for each Bazel Target). To lower resource consumption, Language Server could keep a handful of compiler instances up and assign Compilation Environments as needed in a LRU fashion. Does that make sense?
In fact, that's the approach I invested some time so far.
Out of curiosity, do you have anything publicly available, or was it just more planning / very early work?
@Igorgatis Pinging on this topic. Is there anything we can do to help posting this forward?
Sorry, no progress made. My company ended up using Intellij with Bazel plugin which is still far from a good IDE experience with Bazel.
Bummer, was hoping there was some progress here or a magical way for bazel to generate something to help this language server work. As of now, I have a variety of dependencies that aren't detecting when starting this language server, presumably because it is not aware of the needed dependencies since it does not process bazel BUILD files among other configs.
bit of a dead thread, but just confirming this is still desirable and missing in late 2023 if somebody wants to figure it out
I have somewhat of a working prototype that has Bazel support. The thoughts behind my approach are:
- The language service needs another class path resolver like it has for gradle/maven.
- Bazel handles dependencies/transitive closures on a WORKSPACE file level, so we'd have one global resolver rather than at BUILD file level.
- Have a bazel aspect that emits additional artifacts during a build that are relevent for the LSP (paths of classpath jar entries, source jar entries and source files relevant to the target)
- The incremental compilation right now tries to get all the source files in a workspace root and compiles them along with one file. This makes sense for maven/gradle but not for Bazel since source files are defined on a per-target level. Also this is responsible for huge amount of memory/CPU usage in larger repos. So I had to modify the approach to watch only source files related to the targets that have been built as those are the smallest units of compilation that's possible with all other dependencies within the repo coming in as compiled jars in the classpath entries. This also means we need to constantly keep track of the source files required for compilation as users build targets.
- I had to figure out a way to "refresh" the class path and the source files whenever a build completes. So I had to update the kotlin extension to also watch out for certain file types in
bazel-out/*and handle it in the WorkspaceService implementation.
It's not perfect at this point and some details still need to be resolved but it is moderately usable at this point. If anyone else has thoughts or there's interest in taking a look at a PR, I'd be happy to bring it forward.
