I reached a point where JETLS.JL is good enough for me and has no serious issues anymore. Well, apart from this one, but it can be worked around.
I needed some special configuration, though, and I want to share it with you:
I find it much better than the old language server because it also works in tests and examples of a project and gives warnings that otherwise do not appear, such as warnings about abstract types.
LanguageServer.jl not working on tests is one of my greatest pain points with it. That and the lack of support for package extensions.
Do you know if JETLS.jl work well with code in a Package extension module?
I have also had a positive experience with JETLS. I am using it in emacs. For anyone who might be trying it out in emacs 29 with eglot, it might help to know that this issue is solved in recent versions of eglot. So you might want to upgrade to eglot 1.21. It took me too long to figure that out.
I really like JETLS.jl as well. As of right now I cannot use it due to a weird race condition that prevents the process from exiting. This is primarily in Neovim. But up until the introduction of that bug it was a joy to use and I’m looking forward to using it again. 
Very cool stuff.
Is there some reason you can’t go back to whatever release was working for you? I was assuming that there might be bumps along the road in development and I might have to do that at some point. (Although that hasn’t happened for me so far.)
No reason at all. I just don’t remember which version was working. So I’m guessing is faster to try the next could of versions instead given how fast the development is going.
This was due to an issue with Neovim’s abnormal server process lifecycle handling (i.e. Neovim actually doesn’t comply with LSP by not sending exit notification before killing server process), but it has been fixed on the latest JETLS version 2026-03-13 by making JETLS’s abnormal server shutdown handling more robust. Thanks for @abap34 for this.