(The Scala Center team is dedicated to providing regular and transparent community updates about project plans & progress we develop or support. In this forum we created a new topic category to allow quicker orientation going forward: “Scala Center Updates”. Even though all feedback is welcome, we keep the right to make executive decisions about projects we lead. Overview of all our activities can always be found at https://scala.epfl.ch/records.html)
You can try it right now with the latest Metals snapshot, and it’ll be available out-of-the-box in the upcoming Metals release. When opening a
.sc script, metals proposes to import the script, which starts the latest Ammonite version that Metals support, with metals’ default scala version.
Code navigation, hover information, completion, diagnostics, already work.
Since its inception, Scala is meant to be the “scalable language, designed to grow with the demands of its users, from writing small scripts to building large systems” . Scala scripting mainly means using Ammonite these days. While most Scala IDEs work great for large projects, they provide almost no support for small scripts. Scala script authors don’t benefit from code completion, code navigation, diagnostics right from their editor, etc., which hampers the adoption of Scala for scripts.
To address that, the Scala Center recently collaborated with myself (Alexandre Archambault) to add Ammonite support to metals.
What is it?
We ensured a number of Metals features work for scripts, most notably:
- accurate diagnostics,
- code completion,
- code navigation,
- hover information.
How we did it in more details
This required developments in both Ammonite and Metals.
Developments in Ammonite consisted mainly in:
- writing a new script processor, more extensible than the current one,
- adding BSP support to the new script processor,
- adding the ability to generate correct SemanticDBs for scripts.
The new script processor provides more isolation between scripts (previously, a script could sometimes “see” another script dependencies, even when it had no dependency whatsover towards it).
Developments in Metals consisted mainly in:
- having the ability to fetch and start Ammonite from Metals,
- adding some early support for several BSP connections at the same time in Metals (Metals assumed there was only one BSP connection for the whole workspace, to bloop most of the time),
- having Metals convert scripts (
.scfiles) to valid Scala (
.scalafiles), that it can pass to scalac, for completion, hover, etc., then convert back Scala positions to script positions.
These were done in a single pull request, #1538.
What’s its status?
Both of these developments were merged in Ammonite, and more recently in Metals. BSP support was both merged and released in Ammonite, and Ammonite support in Metals will be part of its upcoming release.
We worked on this support in a limited amount of time. Many things could be added / refined:
- the new script processor in Ammonite could be made the default script runner (right now, it lacks support for running what it parsed / processed / compiled),
- the new script processor could cache things more, both on disk (not to lose data between runs), and in memory (caching compiler instances for even more crispy feedback),
- completion for
import $filein Metals is missing metals#1770,
- the ability to run scripts right from your editor via Metals is missing metals-feature-requests#128,
- maybe the ability to debug scripts from your editor via Metals could be added too.
We are grateful to Li Haoyi, who accepted the (quite large) BSP-related changes in Ammonite, and to the Metals maintainers and contributors, who reviewed the Metals changes, and provided very valuable feedback, making the use of these features less surprising and more pleasant for new users.