LanguageServer.jl keeping JSON.jl at very old version

Tooling Package Management
,
1

I’m posting this under “Package Management” because I’m hoping that there’s some trick of package dependencies I can use to resolve it. (And my apologies if there is an obvious solution to this – I’m relatively new to Julia)

I use LanguageServer.jl as an LSP for my editor (helix), which generally works great. But LanguageServer.jl currently requires JSON = "0.20, 0.21", which is an extremely outdated version of JSON.jl (last 0.21 release was in April 2023; current version is 1.4.0).

JSON 1.0 made a number of breaking changes, so I understand why LanguageServer hasn’t updated. At the same time, I need features from the more recent JSON versions. The two options I can see are:

  1. Don’t use an LSP when coding in Julia (not a great option)
  2. Use a “LSP” project:
    • Install LanguageServer in a separate project
    • Point my editor to load Julia from that project
    • keep the installed packages in the LanguageServer project in sync with my working project/environment manually
    • Ignore all of the JSON-related errors the LSP now finds in my code

Obviously, neither of these options is ideal. Is there another way? It would be great if the JSON used by LanguageServer could be restricted to its functions/namespaces while I am able to use the most recent version for my code.

This seems like a general issue, aside from just JSON: LanguageServer essentially sets global limits on any package dependencies it has.

My broad question is this: is there any way to resolve this issue more cleanly than options 1 or 2 above?

In case it’s relevant: I’m using Julia v1.12.4 and LanguageServer v4.5.1

Thanks!

2

One thing we could look into is using the “vendored” JSONX.jl that the post-1.0 JSON.jl package includes (here: JSON.jl/vendor at master · JuliaIO/JSON.jl · GitHub). That’s what IJulia.jl does in a similar situation where it’s often included as a “utility” for projects, but we don’t want it to interfere with the application JSON dependency.

1 Like
3

Oh, that’s interesting, thanks. JSONX doesn’t have the features I need (lazy parsing, mainly), but would the idea be for LanguageServer to depend on JSONX instead of the “application” JSON library?

It does still make me wish that Julia had some kind of using JSON@0.20 syntax so that packages could use a specific version of a library and be precompiled with that code, while users of those packages could load a different version of the package for their code. I guess this would be a pretty big low-level change, but it would resolve a lot of the ecosystem issues I’ve run into with Julia.

4

I am curious that when Pkg was being developed, was this ever a consideration? Are there any downsides to doing it this way?