Skip to main content

Metals v0.9.1 - Lithium

· 12 min read

We're happy to announce the release of Metals v0.9.1, which focused on fixing issues with the recently released Scala 3 support, Ammonite support and a couple of new features.

Commits since last release287
Merged PRs106
Closed issues49
New features5

For full details:

Metals is a language server for Scala that works with VS Code, Vim, Emacs, Sublime Text, Atom and Eclipse. Metals is developed at the Scala Center and VirtusLab with the help from Lunatech along with contributors from the community.


Check out, and give Metals a try!

  • Ammonite support
  • New project provider
  • Worksheet dependency support
  • Multiline string improvements
  • Scala versions 2.13.3, 0.24.0, 0.25.0-RC2 support
  • Dropped support for Scala 0.23.0 and deprecated the 0.24.0-RC1 version.
  • Multiple build tool selection within a workspace

Ammonite support

Thanks to great work by alexarchambault we now support Ammonite script files. Ammonite enables you to create scripts that can easily be ran from the command line, without the overhead of setting up a build tool while still allowing you to download and use dependencies.

The support includes most of the LSP features such as diagnostics, completions, references, go to definition, but does not include running or debugging the scripts. This new feature works by starting an additional Ammonite BSP server that compiles the scripts and provides additional information about them such as Scala version or information about the added dependencies. You can change the default JVM parameters for the server such as -Xmx, which will limit the used memory in Metals settings. These can be added via your metals editor extension using the newly created metals.ammoniteJvmProperties setting. The Ammonite server can also be started and stopped manually using the new commands ammonite-start and ammonite-stop.

Each of the scripts first need to be imported into the Ammonite BSP server, which can be done manually by clicking on the pop up whenever a new script is opened or selecting automatic import at the start, which will import any open scripts automatically.

It's important to note that this is an early approach to Ammonite support, which might still require some improvements both on the Metals and Ammonite side. You can learn more about the new feature or join the discussion in the blogpost on the Scala contributors forum.

Some of the notable features of Ammonite scripts are:

  • Import other scripts: Metals provides completions to select existing files based on the filesystem information
import $file.hello-world
val greeting = hello-world.greeting

val greeting = "Hello world!"
  • Import dependencies:
import $ivy.`com.lihaoyi::scalatags:0.7.0`
import scalatags.Text.all._

val rendered = div("Moo").render
  • Set Scala version:
// scala $scalaVersion

import scala.util.Properties


The Scala version is independent from any build tool used in the workspace and without specifying the exact version it will use the default Ammonite Scala version.

To learn more about Ammonite please visit the documentation website at

Worksheet dependency support

In addition to Ammonite support, which will be useful to anyone interested in Scala scripting, we've also improved the support for Metals Scala worksheets. Thanks to the efforts of olafurpg in mdoc, which powers worksheets, users are now able to import dependencies directly inside of their Scala worksheet with completions and diagnostics working right from the start.


You can add them using the following syntax:


For example:


:: is the same as %% in sbt, which will append the current Scala binary version to the artifact name.

New project provider

Creating new Scala projects is usually a bit of work to get started, which is a problem for both beginners and experts alike. Normally you don't want to spend a lot of time figuring out the best setup for starting with a new technology or the language itself.

There are great tools like giter8, which is used in the sbt new command, that enables people to use already existing Scala templates found on Github such as The problem is when you don't use sbt or you don't know the exact template you want to use.

To address this, we've added an additional command called New Scala Project that enables users to reuse the same mechanism from the comfort of your editor. Firstly, you can choose from existing templates, either curated by the Metals team, ones existing on the giter8 wiki page or alternatively an entirely custom template. Then you can choose the exact location for the new project and the name. Afterwards, Metals will run giter8 to create the project and offer to open that new project.


The command is also available as a button in the welcome view of the Visual Studio Code Metals extension, which means it will be visible in case there are no imported projects in the current workspace.

The first curated templates were chosen by the team, however we are happy to include more so that it's easier for people to discover new amazing libraries or frameworks.

Multiline string improvements

There are two new quality of life improvements when it comes to multiline strings. Firstly, thanks to mlachkar we now automatically add stripMargin method invocation when using newline in a multiline string if that string uses | and has no existing stripMargin:


This behaviour can be disabled in Metals settings using metals.enableStripMarginOnTypeFormatting.

Another useful improvement coming from colineto is a new code action that can easily convert single string into the traditional multiline string with | and stripMargin at the end:


Multiple workspace build tools selection

Previously, Metals would only pick up a single build tool in a workspace even if in reality there were multiple available ones. To help with that we added a prompt to choose the desired build tool in workspaces with multiple build files.

An example situation where this is needed is when you have a project with both a build.sbt and, but the is what you use for your build definition. Previously if both were detected, it was automatically considered an Sbt workspace, however now it's possible to choose.


In case of multiple build tools in single workspace you can see which one was used to import project in 'Metals Doctor' view. If you choose the wrong one, or change the main build tool later on, you'll need to remove the .metals/ directory to reset the decisions.

This great new feature was contributed by ckipp01!

Miscellaneous improvements

  • Fix run/debug in Maven workspaces.
  • Always run newest sbt version if none is specified.
  • Fix find references for Scala 3 on Windows.
  • Pick jvm targets with higher priority when using run/debug without specifying the exact build target.
  • Make breakpoints work properly in Scala 3 and in case of nested classes.
  • Exhaustive pattern matching in the case of sealed upper bound types.
  • Compile before renaming instead of showing an error.
  • Fix issue with symlinked source directories.
  • Fix missing references for synthetic companion objects.
  • Automatically add -J if it doesn't already exist to java properties when running or debugging.
  • Fix go to definition for JDK 11 library sources.
  • Keep modifiers when implementing abstract members.
  • Fix auto imports position when using package objects and multiple package definitions.
  • Fix issues in files with Scala 2.13 specific syntax like for example underscore numeric literals (val num = 100_000).
  • Always run Mill in interactive mode.
  • Improvements to hover in Scala 3 files.
  • Make sure auto imports are correct for Ammonite scripts


Big thanks to everybody who contributed to this release or reported an issue!

$ git shortlog -sn --no-merges v0.9.0..v0.9.1
Tomasz Godzik
Scala Steward
Alexandre Archambault
Chris Kipp
Łukasz Trojanowski
Coline Thomas
Krzysztof Bochenek
Meriam Lachkar
Daniel King
Naoki Takezoe
Olafur Pall Geirsson
Win Wang
Martin Duhem
Łukasz Wawrzyk

Merged PRs

v0.9.1 (2020-07-01)

Full Changelog

Merged pull requests: