JETLS.jl: A Compiler-Powered Language Server for Julia, Still in the Lab

What JETLS actually targets

JETLS.jl is a language server for Julia, but it is not another reimplementation of the existing LanguageServer.jl. The README states the goal: to provide advanced static analysis and integration with the Julia runtime. The intended users are Julia developers who want editor features that understand types and macros, not just syntax. The project is explicitly experimental. The warning at the top says it is under active development, not production-ready, and that APIs and behavior may change. That is a direct statement, not a caveat buried in the docs. If you are looking for a drop-in replacement for your current Julia editor setup, this is not it yet.

How it works: compiler-driven analysis

The mechanism is visible in the list of dependencies. JETLS builds on JET.jl, which performs static analysis by running Julia's compiler on code and reporting type instabilities and possible errors. It also uses JuliaSyntax.jl and JuliaLowering.jl, which are the parser and lowering stages of the Julia compiler itself. That means JETLS does not parse Julia with its own ad-hoc parser. It uses the same front-end that the language uses. This is a fundamentally different approach from a server that only reads source text. The README mentions two concrete features that fall out of this: type-sensitive diagnostics and macro-aware go-to definition. Macro-aware definition is something a purely syntactic server cannot do reliably, because macros rewrite code before it is analyzed. By hooking into lowering, JETLS can see what the macro actually expands to.

The version constraint is a hard boundary

The README is blunt about supported Julia versions: JETLS supports Julia 1.12.2 through 1.13. It does not support 1.12.1 or earlier, nor 1.14 or nightly. This is not a soft recommendation. It is a hard compatibility boundary. If you are on an older Julia, the server will not work. If you are on a newer nightly, it will not work. This is a direct consequence of depending on internal compiler components like JuliaSyntax and JuliaLowering. Those are not stable public APIs. They change with each Julia release. So JETLS is tied to a narrow window of Julia versions, and that window will move as Julia evolves. For a project that is already experimental, this narrows the audience considerably.

Getting it running: editor integrations first

The README does not give a single install command. Instead, it points to the user guide documentation for installation and configuration. What it does list are editor integrations. The reference VSCode extension is aviatesk/jetls-vscode, published as jetls-client on the Visual Studio Marketplace. There is also a Zed extension in aviatesk/zed-julia. The README says setup for these and other editors is covered in the Editor setup section of the user guide. So the practical path is: install the VSCode extension or the Zed extension, then follow the guide. There is no standalone binary or simple julia -e install shown here. That means the first thing you must verify is whether your editor has a maintained integration. If you use another editor, you are on your own, at least until someone writes a client.

What the documentation does not tell you

The README is short, and it does not include any performance numbers, benchmark results, or user counts. There is no claim about how fast the server starts or how much memory it uses. There is no comparison to the existing LanguageServer.jl. The only stated facts are the goal, the dependencies, the version support, and the experimental warning. That is a notable absence. For a tool that promises compiler-powered analysis, the cost of that analysis is the first thing an engineer would ask. The README does not say whether type-sensitive diagnostics are computed on every keystroke or on save. It does not say whether macro-aware go-to definition works across packages or only within a single file. Without that information, you cannot estimate whether JETLS will be usable on a large codebase. You have to try it, and the experimental warning suggests you should expect rough edges.

The real alternative: LanguageServer.jl

The obvious alternative is LanguageServer.jl, the existing language server for Julia that has been in use for years. The difference in approach is fundamental. LanguageServer.jl is built on static analysis of source text, using Julia's parser and its own symbol table. It does not run the compiler on your code to find type errors. JETLS, by contrast, uses JET.jl to run the compiler's type inference and report errors and instabilities. That means JETLS can catch errors that only appear during inference, such as a method that is never called with the right types. LanguageServer.jl cannot do that. But LanguageServer.jl is mature, stable, and supports a wide range of Julia versions. JETLS is new, experimental, and locked to a narrow Julia version range. So the trade-off is depth of analysis versus breadth of compatibility and maturity. If you need reliable autocomplete and go-to-definition today, LanguageServer.jl is the safer bet. If you want to experiment with compiler-powered diagnostics, JETLS is the only option in this space.

Maintenance and upgrade cost

The release history shows a rapid pace: releases on 2026-08-23, 2026-08-28, and 2026-08-29. That is three releases in a week. This tells you the project is moving fast, but it also means you will be updating often. Every time Julia releases a new version, JETLS may need to be updated to track the compiler internals. The README's version warning makes that explicit. The license is MIT, which is permissive and imposes no restrictions on commercial use, but that does not reduce the maintenance burden. You are responsible for keeping the server and your editor integration in sync. The AGENTS.md file, mentioned in the development notes, suggests the project has specific coding rules, which is good for contributors but irrelevant to end users. In short, expect a high upgrade cadence and a narrow compatibility window. That is the cost of using a compiler-powered tool.

Editorial conclusion

Adopt JETLS.jl if you are a Julia developer on Julia 1.12.2 through 1.13 who wants early access to compiler-powered diagnostics and macro-aware navigation, and you accept frequent breaking changes and limited stability. Do not adopt it if you need a stable tool for daily work, or if you are on Julia 1.12.1 or earlier, or on 1.14 or nightly. Before using it, verify that your editor integration (the VSCode extension or the Zed extension) supports your setup, and check the user guide for current configuration options. The project is explicit that APIs and behavior may change, so pin your Julia version and be ready to update frequently. The real question is not whether JETLS is good today, but whether its compiler-based approach will outpace the existing static-analysis server; the repository gives no evidence of that yet.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes