haskell-language-server: the official LSP server for Haskell, and what it costs to run

What haskell-language-server solves for Haskell editor users

Editing Haskell without a language server means running ghc or ghci in a separate terminal and reading errors by hand. The README describes haskell-language-server as "The official Haskell language server (LSP) implementation", which is the whole pitch: an editor-agnostic process that answers LSP requests for the file you are editing. The audience is anyone who already has a Haskell project that compiles and wants the editor to know about it. It is not a compiler replacement and not a linter you run in CI. The repository is Apache-2.0, the default branch is master, and the most recent release listed is 2.15.0.0 from 2026-09-03. The last push to the repository was on 2026-09-23.

How the server, ghcide and the plugins fit together

The repository layout is the clearest description of the architecture. There is a ghcide/ directory, a hls-plugin-api/ directory, a plugins/ directory, and an exe/ directory. ghcide is the underlying engine that tracks modules and produces type information; hls-plugin-api is the interface plugin authors code against; plugins/ holds the individual features; exe/ builds the executable your editor launches. The README lists Features, Configuration and Components as separate documentation pages, which matches that split: the server binary is thin, and the behaviour you actually see comes from whichever plugins are enabled for the project. That design is why two Haskell projects can produce very different editor experiences from the same hls binary. A plugin that needs a build plan will only work when the plan resolves. The docs also maintain a Supported GHC Versions page, which is the constraint that shapes everything else: the server is compiled against particular GHC releases, so your compiler choice limits which server release you can use.

Installing haskell-language-server and opening a first file

The README does not inline install commands; it points at an Installation page in the project documentation, and the package is published on Hackage as haskell-language-server. The repository also carries flake.nix, default.nix and shell.nix, so a Nix path exists, and stack.yaml plus stack-lts24.yaml exist for Stack-based builds. The version you install has to match your GHC, so check the Supported GHC Versions page before picking a release tag.

The README gives no command to copy, so the honest first step is to open the Installation page it links to and follow the route that matches your build tool. What you should end up with is an hls executable that your editor's LSP client can start. If the editor shows no diagnostics at all, the usual cause is that the server started but could not find a build plan for the project.

The GHC version matrix is the real constraint

Every release of haskell-language-server is tied to a set of GHC versions, and the project keeps that list on a dedicated Supported GHC Versions page rather than in the README. This is the limitation that decides adoption more often than any feature gap. If your project is pinned to a GHC release outside the supported set, you cannot simply install the newest server and expect it to work; you either move the compiler or install an older server release. The release history shows how fast the matrix moves: 2.13.0.0 in January 2026, 2.14.0.0 in April, 2.15.0.0 in September. Teams that pin a compiler for reproducibility will find themselves pinning the server too, and that pin has to be revisited whenever the compiler moves. The README does not document a rollback procedure for a server upgrade that breaks an editor setup, so treat the version pin as something you manage deliberately.

When haskell-language-server is the wrong tool

The server depends on a resolvable build configuration for the project you are editing. That makes it a poor fit for single-file scratch work, for a repository whose dependencies no longer resolve, or for a machine where the project has never been built. In those cases the editor will start the server and get little back, and the failure looks like silence rather than an error message. It is also the wrong tool if you only want syntax highlighting or bracket matching; those come from your editor's own grammar support and do not need an LSP process at all. Finally, if your workflow is batch checking rather than interactive editing, running the compiler directly gives you the same diagnostics without a long-lived server process, and the project's own documentation is organised around editor use rather than CI use.

Alternatives and how their approach differs

The most direct alternative is to skip the language server and use ghci or ghc directly from the editor or a terminal. That gives you the same compiler diagnostics with no server process and no GHC-to-server version matrix, but you lose the LSP features the README lists, such as the editor-integrated behaviour described on the Features page, and you have to re-run the compiler yourself after each edit. A second alternative is a Haskell-specific editor integration that predates LSP and talks to the compiler through its own protocol. Those integrations are tied to one editor, while haskell-language-server is editor-agnostic by construction, which is the reason the project exists as a separate binary. The trade is that the generic path has more moving parts: a server process, an editor client and a build plan that all have to agree.

Maintenance, upgrades and what the Apache-2.0 licence means here

The repository is not archived and the last push was on 2026-09-23, one day before this article's reference point, so the project is receiving changes. Release cadence in 2026 has been roughly quarterly, which sets the upgrade rhythm: expect a new release every few months, each with its own supported GHC set. Budget for the upgrade as a version-matrix check, not just a binary swap. The repository includes a ChangeLog.md and a RELEASING.md, so the project documents its own release process, and there is a GenChangelogs.hs at the top level, which suggests changelog generation is scripted. On licensing, the project is Apache-2.0 and the README carries the licence badge and a link to the LICENSE file. Apache-2.0 is a permissive licence with an explicit patent grant, but this is a description of the licence identifier, not legal advice; if you redistribute the server or embed it in a product, read the LICENSE file yourself.

Editorial conclusion

Adopt haskell-language-server if you write Haskell in an editor that speaks LSP and your project builds with a GHC release the project lists as supported. Skip it if you only need syntax highlighting, or if you cannot keep a working build plan for the project you are editing, because the server reuses the build configuration rather than guessing types on its own. Before committing, confirm the supported GHC version page covers your compiler, that your editor's LSP client is wired to the hls binary, and that your cabal.project or stack.yaml resolves in a clean environment.

Frequently asked questions

Official sources

1. haskell/haskell-language-server on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases