Metals is a Scala language server that brings rich IDE features to editors supporting the Language Server Protocol, aimed at Scala developers who want full tooling outside of IntelliJ IDEA.
What it is
Metals is an open-source language server written in Scala, released under the Apache-2.0 licence, and its name is a blend of Meta (from Scalameta) and LS (from Language Server). It implements the Language Server Protocol (LSP), which means it plugs into any code editor that speaks LSP and supplies the language-aware behaviour that editors otherwise lack, together with the rich IDE feature set described by the project. It is part of the Scalameta ecosystem, whose homepage at scalameta.org/metals carries the project's documentation, contribution guide, and background on its development.
The concrete problem it solves is the gap between a plain text editor and a Scala-aware IDE: Scala is a complex language, and editors such as Vim, Emacs, or VS Code do not natively understand Scala projects, their build definitions, or their type information. Metals fills that gap by acting as an intermediary that understands the codebase and answers the editor's requests, so that developers who do not want to work in a heavyweight IDE still get usable language intelligence. The project explicitly frames itself as an alternative to IntelliJ IDEA, whose Scala support relies on a re-implementation of the Scala typechecker, whereas Metals works through the standard protocol and the Scalameta tooling.
Key capabilities
- Implements the Language Server Protocol (LSP) for Scala, so it integrates with any LSP-capable editor rather than binding to a single one.
- Provides what the project describes as rich IDE features for Scala development.
- Is built on Scalameta, the Scala metaprogramming library from which the project takes the first half of its name.
- Offers a documented internal architecture in the repository's
architecture.md, which explains the high-level layout of the source code for contributors.
- Ships a contributing guide at
scalameta.org/metals/docs/contributors/getting-started.html for people working on the code itself.
- Is developed in public through the Scala Tooling Spree, a series of regular online events open to anyone contributing to Scala tooling.
- Accepts community contributions under Hacktoberfest, with 2,333 stars, 445 forks, and 282 open issues recorded on the repository.
Who uses it and how
- Scala developers who prefer editors outside JetBrains' ecosystem and want Scala language support through LSP instead of IntelliJ IDEA.
- Contributors to Scala tooling generally, who join the recurring online Scala Tooling Spree events to work on the project together.
- New contributors following the getting-started guide and reading
architecture.md to understand the codebase before submitting changes.
- Open-source participants taking part in Hacktoberfest-style contribution drives on the repository.
Getting started
The README does not list a package or image; it directs readers to the project website at https://scalameta.org/metals/ for documentation, and to the contributing guide at scalameta.org/metals/docs/contributors/getting-started.html for setting up a development environment.
How it compares
Metals stands as the language-server route to Scala tooling alongside IntelliJ IDEA, which the project names as its alternative and describes as the most widely used Scala IDE. The distinction the project draws is architectural: IntelliJ IDEA uses a re-implementation of the Scala typechecker, while Metals delivers its features through the Language Server Protocol and Scalameta. Both are free to use, but they serve different editing environments.
When to use it β and when not to
It is the right choice when you want Scala support in an LSP-based editor and are content to follow documentation hosted on the project website rather than in the README. Because the README itself is thin β pointing outward to the website, the contributing guide, and architecture.md β anyone evaluating it should expect to read those linked pages to learn about features, install methods, and current stability. Conversely, developers already settled in IntelliJ IDEA, or those who prefer its typechecker-based tooling, have little reason to switch, and the 282 open issues suggest a project with a substantial outstanding backlog.