I reached out to some authors and devs familiar with each tool in order to be as fair as possible. Each of these tools is a large undertaking and takes tons of time and effort from the maintainers. A simple 2D comparison table can’t tell the whole story, so take it with a grain of salt. I’ll be doing my best to maintain and update the list as tooling evolves and adds/changes functionality.
Not sure where you’d like specific content discussion (here or in the GitHub comments section).
A couple notes:
Including which mainstream editors have packages for simple installation would be useful in the list. EDIT: sorry I was just blind… you’ve got it.
I have anecdotal experience that ElixirLS works with monorepos, depending on exactly what you mean by monorepo support. My current project is a monorepo style project with many Elixir projects inside the “project workspace” of my editors. I have have worked this in both VSCode and in my current editor, Sublime Text. Here’s a screenshot of a few sample directories in the larger project workspace; note the .elixir_ls built in the root of each Elixir project:
Hmmm… at some level, for a checklist like the OP published, this feels like an odd dividing line between “monorepo support: yes” vs. “monorepo support: no or unknown”. My sense is that it conflates a feature, can the tool be used with monorepos, with the implementation details of how the feature is implemented. As a simple user, what I first want to know is does the tool allow me to work across the multiple Elixir projects in my monorepo: in a simple checklist sense this to me sounds like a “yes” for ElixirLS (I’ve not tried the others). Now to be fair to your point, there may be reasons why the ElixirLS implementation of that kind of support is inferior that of NextLS. But depending on the nature of my project I may never reach a point where that distinction actually matters in practice.
Finally, if we are to take the disclaimers at the top of the list at face value:
This comparison does not take performance into account.
Language servers might support similar features that operate differently.
It seems as though the implementation difference you describe shouldn’t be a factor in deciding if a feature is supported or not. If there are actual feature differences, meaning I as a user gain or lose capabilities in working with the monorepo, the argument will be on firmer footing.
ElixirLS works with VSCode multi-root workspaces but the support for that is implemented in VSCode extension. It currently starts separate language server processes in each workspace directory. I’m not aware if multi-root workspaces are supported in other editor extensions wrapping ElixirLS
I think this is a better example of “feature” that I was trying to get at. I don’t really have much call for this sort of thing myself, but I could see other scenarios where it might be useful. I also see why the earlier distinction you were trying to make was being pointed out, and in the context of the above it makes more sense.
Seems to be in Sublime Text. This is the functionality I most depend on in my project; as you point out, back when I was using VSCode I had it working there, too.
To be honest, the way the different Elixir projects are used in my code base, per workspace directory LSP processes don’t bother me and is consistent with what I need to manage the monorepo in the editor.