Haskell · tooling · editor

Haskell Language Server (HLS) in 2026: setup and common fixes

By ColdwastUpdated Jun 14, 20267 min read#haskell#hls#editor

Source code open in a code editor — HLS brings IDE features — types, completion, refactors — to any editor that speaks LSP.

Writing Haskell without an IDE backend means squinting at type errors after every compile. The Haskell Language Server (HLS) fixes that: it implements the Language Server Protocol (LSP), giving you inline types, autocompletion, go-to-definition, hover docs and refactors in VS Code, Neovim and other editors. This guide covers what HLS is, how to install it cleanly in 2026, wiring it into your editor, and the handful of errors that trip people up.

What HLS actually does

HLS is a single server that editors talk to over LSP. It provides:

Type information on hover and inline.
Autocompletion and import suggestions.
Go-to-definition, find-references and document symbols.
Code actions: add a missing import, fill a type signature, apply a hint.
Linting via integrated hlint suggestions.

Because it speaks LSP, the same server powers every editor — you install HLS once and pick a client plugin.

Installing HLS with GHCup

The clean path is the same toolchain manager you use for the compiler. If you have not set up the toolchain yet, start with our GHCup install guide, then add HLS:

ghcup install hls recommended
ghcup set hls recommended

The single most important rule: HLS must support your active GHC version. Install the HLS build that matches the GHC you compile with — the interactive ghcup tui shows which HLS versions cover which GHCs.

Wiring it into your editor

Lines of source code on a dark screen — HLS surfaces types and errors as you type.

VS Code: install the official Haskell extension; it can manage HLS for you or use your GHCup-installed one. Point it at the GHCup HLS to avoid version drift.
Neovim: configure haskell-tools.nvim or the built-in LSP client with haskell-language-server-wrapper on your PATH.
Other editors: any LSP-capable editor (Emacs with lsp-mode, Helix, Zed) works — point it at the haskell-language-server-wrapper binary.

The -wrapper binary auto-selects the right HLS for each project's GHC, which is why pointing your editor at it (rather than a fixed version) avoids most mismatches.

Common errors and fixes

"No HLS version for GHC X.Y". Your GHC is newer than any installed HLS. Update HLS via ghcup tui, or switch the project to a GHC that HLS supports.
HLS keeps restarting / out of memory. Large projects can exhaust RAM during indexing; close other tools, and ensure your machine has enough memory for the project size.
"cradle" errors / wrong components. HLS reads your build via the project files; make sure the project builds with cabal build first, and that an hie.yaml is only added when auto-detection fails.
Stale results after a dependency change. Restart the language server from your editor; HLS caches the build plan.

A reliable rule: if HLS misbehaves, confirm the project compiles from the command line first — see how parallel builds work in how Cabal uses your cores, and the build-model background in Cabal 2.0.

FAQ

Is HLS free and official? Yes — it is the open-source, community-standard language server for Haskell, installable through GHCup.

Do I need Cabal or Stack for HLS? HLS reads whichever build system your project uses; it works with both Cabal and Stack projects.

Why does HLS need to match my GHC? HLS is built against a specific GHC API, so each HLS build supports a set of GHC versions. Use the wrapper binary to auto-select the right one per project.

Does HLS work on Windows? Yes, via GHCup's Windows installer and the same editor extensions.

Independent, community-maintained guide. coldwa.st is a programming-resources site; this article is new, original writing about the Haskell Language Server and the current toolchain, not affiliated with or authored by the project's maintainers. Commands reflect documented HLS/GHCup behaviour — check the official docs for the latest version coverage.