We're happy to announce the release of Metals v0.9.6, which mostly concentrates
on adding support for the newly released Scala 2.13.4, but also adds some
improvements for already existing features.
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.
Last
release
introduced the option to display additional data inferred from the code to a
user. Starting with this release it's also possible to show implicit conversions
and classes, which can be enabled by the additional
showImplicitConversionsAndClasses setting. Moreover, Visual Studio Code
extension has 3 new commands to toggle all these new options, which enables
users to quickly peek at the additional information about their code and then
turn it back off. All these commands can be bound to a shortcut to further
improve the user experience.
Any editor that allows for quickly changing these settings will also benefit
from this change, as the file's decorations are refreshed instantly upon
changing any of those settings.
Navigating stacktrace
Previously, it was possible to navigate a stacktrace using the
Analyze stacktrace command which was added in the
v0.9.4
release. It turns out, we can reuse the same mechanism to show file links in the
Debug Console in Visual Studio code:
This was achieved by adding additional information to the output already sent to
the editor, so this additional file links should also be reused by any other DAP
clients.
Troubleshooting
As an addition to these new features, we've also recently added a new
troubleshooting page that should answer
the most basic questions you can have. As the page is fairly new we would appreciate
any help in improving it so let us know if you feel anything is missing.
Miscellaneous
Fix continuous compilation when opening tree view in sbt BSP
Add 0.27.0-RC1 back to supported versions
Contributors
Big thanks to everybody who contributed to this release or reported an issue!
$ git shortlog -sn --no-merges v0.9.5..v0.9.6
Tomasz Godzik
Scala Steward
Chris Kipp
Gabriele Petronella
Krzysiek Bochenek
dependabot[bot]
We're happy to announce the release of Metals v0.9.5, which brings about some of
the long awaited features such as implicit decorations and the organize imports
code action. We also greatly simplified connecting to the sbt BSP server and
added support for Scala 3's first milestone 3.0.0-M1.
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.
Show implicit parameters and inferred type decorations.
Improved sbt BSP support.
Support for Scala 3.0.0-M1.
Remote debugging.
Environment variables in run/debug.
Organize imports code action
One of the most requested features in the Metals repository, current list can be
found here, was the ability to
automatically organize imports. We are happy to announce, that thanks to
mlachkar's amazing contributions to both
Scalafix and Metals, this new feature
is now available via an Organize imports code action.
Depending on the editor this code action can be invoked differently, please
consult your specific editor's documentation. For example in Visual Studio Code
'organize imports' can be invoked from command console, shortcut, or from the
dropdown menu when right clicking inside a file.
The organize imports code action is enabled using
Scalafix and specifically the awesome
organize imports rule created by liancheng.
The rule can be used to automatically sort imports in a file by the Ascii order,
which is the default setting, or use the user specific configuration defined
using scalafix configuration file. This file can be either .scalafix.conf in
the current workspace or an absolute file specified in the
metals.scalafixConfigPath user setting. It's important to note that the new
code action is consistent with how sbt's scalafix plugin will behave.
An example scalafix configuration for the organize imports rule can look like
this:
import java.lang.{Long => JLong}
import scala.collection.mutable.ArrayBufferobjectRemoveUnused{
val buffer: ArrayBuffer[Int] = ArrayBuffer.empty[Int]
val long: JLong = JLong.parseLong("0")
}
Please do NOT use the Scalafix built-in RemoveUnused.imports together with
OrganizeImports to remove unused imports, since it might result in a broken
code.
Another highly anticipated feature was the ability to show additional
information about the code, which is not provided explicitly. In this new
release, users can use two new options when looking through their code:
metals.showImplicitArguments will enable users to see implicit parameters
within their code:
metals.showInferredType will enable users to see inferred type for any
generic methods they are using:
Both new options are disabled by default, since they add a great number of
information, which might not be necessary for all users. Full name with package
for each of the additional types or values will be available on hover.
These options can be set in Metals options in VS Code or in Emacs
(lsp-metals) using
lsp-metals-show-implicit-arguments and lsp-metals-show-inferred-type
variables set to t.
Unfortunately, due to current limitations, additional decorations are only
possible in Visual Studio Code and Emacs. In other editors the additional
information is available via hover and new With synthetics added section,
which shows how the whole current line would look with the additional
decorations.
Example of how this alternative approach looks in Vim:
Improved sbt BSP support
In recent months, eed3si9n and
adpi2 worked, under the auspices of Scala Center, on
making sbt capable of acting as a
Build Server Protocol server. This
enables Metals and other editors such as Intellij IDEA to directly communicate
with sbt in order to compile the user's code.
Some more work was required in order to make the new features work smoothly with
Metals and currently, thanks to ckipp01, users can
easily try out the new sbt BSP support. It's important to note that using Bloop
instead of sbt is still the recommended approach as we believe it provides the
best user experience and features like running or debugging are still not yet
implemented for sbt. More details and explanations can be found in the
blogpost.
Remote debugging
Thanks to the great work of pvid, Metals now supports
remote debugging, which means that it can attach to a running process with the
proper JVM options specified. There is no longer a need to run the application
or test from within the editor.
In case of a simple java process those options will take a form of for example:
suspend=y will make the process wait for Metals to connect to it if
specified to y. n will cause the process to run normally.
address=5005 specifies which port to use and it can be any free port.
For a detailed explanation of the different options please refer to the proper
documentation
here
When using sbt, remote debugging can be achieved by specifying additional
settings:
javaOptions in run := List("-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005"),
fork in run := true
This will cause running sbt run to wait for Metals to connect to it, which
might be especially useful when reading user input, which is currently
impossible to do for example from within VS Code. Similarly, these options can
be specified in any of the supported build tools.
To later connect to the running process, you need to use the additional Attach
request type with the buildTarget, hostname and port fields specified. In
case of Visual Studio Code this will take a form of:
# single line valueskey1=value 1
key2='value 2' # ignored inline comment
key3="value 3"# multi-line valueskey4='line 1
line 2'key5="line 1
line 2"# export statementsexportkey6=value 6
# comma delimiter
key7:value 6
# keys cannot contain dots or dashes
a.b.key8=value 8 # will be ignored
a-b-key9=value 9 # will be ignored
The format is adapted from
mefellows/sbt-dotenv and
bkeepers/dotenv. Example json
configurations above are defined for Visual Studio Code, the type and name
fields can be omitted when using in other clients.
This new feature has been contributed by mwz. Thanks
for the great work!
Miscellaneous
Removed javax from default excluded packages - it can be added back in the
configuration.
Fixed top level completions in empty files.
Fixed issues with run/debug when using VPN.
Fixed go to java sources in standalone worksheets.
Fixed issues with worksheets if the workspace was not first compiled.
Fixed sbt completions coming from project/*.scala files.
Only use import {java.util => ju} when there are conflicting symbols in the
file.
Muted InvalidProtocolException in the logs - this exception might happen.
normally and does not break anything.
Changed scalafix and scalafmt location in user configuration to absolute path.
Only report parsing errors after Scala version is confirmed for a file.
Added automatic retry in case of build server connection failure.
Contributors
Big thanks to everybody who contributed to this release or reported an issue!
If you've been following the sbt
releases, 1.4.x introduced some great new
features, one of those being BSP support. This effort was initiated by community
members and proposed to the Scala Center Advisory
Board.
Then thanks to the work of Adrien Piquerez and
Eugene Yokota BSP support became a reality in
1.4.0. You can read more about the reason behind the work and some of the
details of the implementation in this blog post: BSP Support in sbt
1.4.
The Metals team is also happy to announce that as of the 0.9.5 release, the
process to use other BSP servers like sbt is now much smoother. In some ways,
BSP is an implementation detail abstracted away from a user, and you may not
directly interact at all with your build server, even though it's pivotal for
the Metals experience. Therefore, we'd like to answer some common questions
about what this means to you as a user, explain some of the default choices
Metals makes for you, and show you how to explore the sbt BSP server.
What is BSP?
First off, you may be wondering what BSP is. The Build Server
Protocol (BSP) is a Protocol for IDEs and
build tools to communicate about compilation, running, testing, debugging, and
much more. If you're familiar with the Language Server
Protocol (LSP), BSP is
complementary to LSP and inspired by it. Where LSP allows your editor to
abstract over various programming languages by a shared way to communicate to a
language server, BSP allows IDE's to abstract over various build servers. A
typical example of this can be illustrated like so:
You have your editor (Emacs) communicating with Metals via LSP, and then Metals
communicating with a BSP server (Bloop) via BSP. This communication over BSP can
be about compiling your code, running your code, defining sources in your
workspace, etc. You can read all about the various communication types here in
the
protocol.
Bloop was the first server to implement
BSP, and it's the default build server for all build tools that Metals supports
at the moment. When you open a fresh project, you're prompted to import your
build, and this import process is running a form of "Bloop Install" to write
your build definition to .bloop/ for Bloop to read and use. Then as you
continue to edit, diagnostics and other information are flowing back and forth
from Metals to Bloop. Hopefully this gives you a brief picture of what BSP is,
and how it's used in Metals.
What does sbt BSP support mean for Metals?
Another question you may have is "what does sbt BSP support mean for Metals"?
This means a couple different things. Up until this point, if you wanted to use
sbt BSP, you needed to clear your .metals/ and .bloop directories, and then
start sbt with a specific flag before connecting to it. None of this is
necessary anymore. In order for BSP
discovery
to happen, you need a .bsp/*json file with instructions on how to
start/connect to the build server. A new command has been added to Metals (which
we'll go over down below) that can generate this file for you if it doesn't
exist, and then you will be automatically connected to sbt. If this file already
exist, then we provide a simple way for you to "switch" build servers and for
your choice to be remembered. We also automatically include an sbt plugin to
ensure the correct semantic information is produced by the compiler. So to
summarize, Metals now has the ability to generate the necessary .bsp/sbt.json
file if it doesn't exist, and to also switch back and forth from using Bloop or
sbt as your build server.
What's the difference between Bloop and sbt BSP?
At this point you may be asking, "what's the difference?". For an average user,
there may not be a ton of difference, however I'd like to outline a couple
things that may be relevant to you.
Bloop supports the Debug Adapter
Protocol (DAP) and sbt
doesn't. So you'll notice when using sbt as a build server, you won't have
the run or debug code lenses directly in your editor like you do with
Bloop.
Bloop writes all the necessary information about your build it needs to disk
whereas sbt loads it into memory. If you're a user that works for long
periods of time on a single project, then this may not matter to you at all.
However, if you jump in and out of projects, without having sbt shell
running, then you will pay the cost of loading up your build every time.
Bloop offers sbt file support that enables completions and hover, whereas
this is not yet available in the sbt BSP implementation.
sbt gives you access to the full task graph, so for example if you're using
BuildInfo, and you compile with Bloop, your BuildInfo won't get
generated. However, sources will get generated when using sbt server. This
can help avoid any potential inconsistencies.
While there are some more differences, these are probably the main ones you'll
notice as a user. These are both great tools, and you'll have to explore more to
see what is the best fit for you. For now, Metals defaults to using Bloop mainly
because we believe it provides a richer feature set and because pretty much all
of our testing includes Bloop as a build server.
How do I try it out?
Now to the good stuff. There are two main ways that you can start using sbt
server in Metals.
No .bsp/sbt.json exists
If no .bsp/sbt.json exists yet, you can generate it with the new
metals.generate-bsp-config command. At any time you can execute this command
and Metals will ensure that you're on the minimum required sbt version (1.4.1),
generate the .bsp/sbt.json file for you, include the necessary plugin, and
then auto-connect to the sbt build server. For example in VS Code this looks
like this:
metals.generate-bsp-config
.bsp/sbt.json already exists
If you've ran sbt on your project already, your .bsp/sbt.json file will
already exist. In this case, you can simply use the metals.bsp-switch command
and choose sbt. For example, using coc-metals, it looks like this:
metals.bsp-switch
Switching back to Bloop
After you do a metals.bsp-switch or metals-generate-bsp-config, your choice
will be remembered. So the next time that you open your workspace, you will
automatically connect to the last build server you had chosen. If you'd like to
go back to your previous build server, you can simply use the
metals.bsp-switch command again to choose your previous server. For editors
that have an html doctor, you can also reset your build server choice in the
Doctor.
Doctor reset
Conclusion
We hope you enjoy this easier way to use sbt server with Metals. If you're
curious about the implementation details, much of the work was done in this
pr. As always please don't
hesitate to ask questions on our various channels, submit issues, or create new
feature requests.
We're happy to announce the release of Metals v0.9.4, which focuses on
improvements in Scala 3 worksheets, a couple of new features, and a number of
smaller improvements.
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.
Thanks to kpbochenek, Metals can now help with
navigating stack traces using the new metals.analyze-stacktrace command. The
only thing it needs is the actual stack trace string to be input as a parameter
to the command. This new functionality works differently in various editors.
Visual Studio Code
The only thing users need to do is copy the stack trace and run the
Analyze Stacktrace command from the command palette. This will display a new
web view, where it will be possible for users to navigate the files that are
included in the exception.
coc-metals
With coc-metals, you just need to copy the stacktrace, whether from sbt,
bloop-cli, or somewhere else into your register. Once you have it copied, you
can just execute the metals.analyze-stacktracecommand. This will create
a.metals/stracktrace.scala file which can be used to navigate through your
stacktrace using code lenses. Keep in mind that you'll want to make sure you
have codeLens.enable set to true in your configuration. Also, since this feature
relies on code lenses (virtual text in Nvim), it's only supported in Nvim.
Other editors
To make it work with any other editors users need to run the command manually
with the stacktrace as input, similar to the example above with coc-metals.
The command will generate a new file, .metals/stacktrace.scala, which can be
used to navigate through the stacktrace using code lenses.
Customizable package exclusions
Usually, a number of packages are almost never used by the developers and could
clutter the language server output while being of little benefit to the users.
Metals would exclude those packages from indexing causing them to not be
recommended for completions, symbol searches, and code actions. Previously that
list was set in stone and consisted of a number of prefixes:
This list might work in most cases, but users might also want to customize the
list according to their preferences and domain they are working on. Starting
with this release it is now possible to define additional exclusions as well as
remove some from the default list. This can be done via an additional Metals
user setting:
-- should only be used to remove some of the defaults if they aren't needed
for your project. Thanks to ckipp01 for
contributing this feature!
Miscellaneous
Some of the smaller improvements to Metals include:
New recommended Maven Scala template.
Fix go to source and auto imports in standalone worksheet files.
Fix missing classes from _empty package in tree view.
Add a command to quickly create a new worksheet with a default name.
Beside all the core work on the server itself, there have also been a lot of
great work done in various other Scalameta projects, which Metals relies on.
These projects include mdoc, which powers
worksheets and Scalameta, which powers
all SemanticDB and parsing powered features. Those contributions helped to
unlock and improve Dotty support in Metals. So special thanks to those projects
and contributors.
Contributors
Big thanks to everybody who contributed to this release or reported an issue!
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.
sbt script support with hover, completions and go to definition.
Scala 3 worksheet support
Scala 0.25.0 and 0.26.0-RC1 support.
Main classes from dependencies can now be run
sbt script support
Thanks to the great work by dos65 Metals now
supports sbt script files as well as build's Scala files. The full list of
currently supported features is available
here.
sbt support is is achived by generating additional metals.sbt file for each
level of sbt's project. For build.sbt we now generate
project/project/metals.sbt, for project/other.sbtproject/project/project/metals.sbt etc. This is needed for the Bloop plugin to
properly generate information in the .bloop configuration files. It's
recommended to gitignore metals.sbt and .bloop anywhere in the file tree.
Scala 3 worksheet support
Finally, it is now possible to run worksheets for Scala 3 starting with version
0.26.0-RC1. To try it out users need to create the worksheet inside of a Scala 3
source directory and then they can be used the same way as with previously
supported worksheets.
This is a great place for anyone to experiment with Scala 3 and see what is
coming around the corner!
Running main classes from dependencies
Previously, users could only run main classes that are defined in the
sourcecode, which made it impossible to run and debug in certain frameworks such
as the Play Framework. Metals now searches the
classpath additionally to find any classes that are defined by the user and not
available in the main sources.
To run any such class a full name needs to be provided via the configuration.
For example in Visual Studio Code this would look like this:
As of this last Metals release, it's now 100% possible to fully configure Metals
without any need to pass in server properties. Depending on your editor of
choice, the process to configure Metals may be completely abstracted away. You
simply click install, wait a bit, and start coding. In this post I'd like to
talk a bit about the progression of how Metals was originally configured fully
with server properties and how it can now be fully configured via the client,
which in LSP terms is
your editor. This can serve both as a guide for those client extension
maintainers out there and also those curious at how Metals correctly works for
all the various editors.
The first configuration
Looking back to the Fall of 2018, you see a giant glimpse of Metals becoming
what it is today when looking at a giant commit by
@olafurpg with the title Implement pretty
basic language server and build
client..
It's a pretty fascinating commit to look at if you're interested in the
beginnings of Metals, but I want to focus in on a specific file that still exists
today, which is the
MetalsServerConfig.scala.
In this file you see the first configuration options that existed for Metals.
You see things like isLogShowMessage to ensure users were correctly getting
status messages instead of everything just going into the logs. (This was also
before
metals/status
existed which is used today for a better status experience in Metals). You also
see other options like isHttpEnabled for Metals to start the Doctor for those
that needed an HTTP client interface, or even an icons setting to ensure
things looked nice and matched your client. At this point, instead of just
having the user specify every one of these when they bootstrapped the server, a
metals.client property was introduced that we could give editors a set of
defaults. Here is an example for the first settings for Vim and Metals using the
vim-lsc plugin:
The property would then be set when the user would bootstrap Metals. This
started out as a manual process for almost all the editors utilizing
Coursier. This still actually remains a
valid way to configure Metals, although not recommended if your client supports
setting InitializationOptions in the
initalize
request. It's also almost the identical process that happens behind the scenes
when client extensions like
metals-vscode,
coc-metals, and
metals-sublime bootstrap the
server for you. For example, here is how you would manually do this:
In the above example, you would then get the defaults specified in
MetalsServerConfig.scala for emacs. Again, when the process is automated
it's very similar, and you can see this if you poke around the
fetchAndLaunchMetals
function in the VS-Code extension. You can see how the path to Coursier is
grabbed, your JAVA_HOME is captured, and how we get some extra
variables/properties to call Metals with.
User configuration
Apart from server properties, it was also necessary for users to be able to
easily change a setting, even while in the editor. For example, we have a
current setting metals.superMethodLensesEnabled which when enabled will
display a code lens that when invoked will either go to the parent class
containing the definition of the method or symbol or display the full method
hierarchy allowing you to choose where to go.
Here is an example of what this looks like in Vim:
This feature is actually turned off by default since in very large code bases
you may experience a lag. So if a user wanted to turn this on, it wouldn't be a
great user experience to have to re-bootstrap the server to enable this feature.
This is where the User Configuration comes into play by being able to change a
configuration value and notify the server via
workspace/didChangeConfiguration.
This can fully happen for most of the user configuration values without any need
to restart the server. You can see the first configuration options added this
way in this
commit
where the ability to define your JAVA_HOME was added. With now allowing for
user configurations in Metals, this allowed for an even more customized
experience.
Experimental
Being able to customize the server with properties and allowing users to pass in
some configuration values worked great. However, once Metals started creating
LSP extensions for functionality that wasn't supported fully just by LSP, then a
way was needed for the client to express that it supported these extensions.
This is when Metals started to use the
ClientCapabilities.experimental
field which the client needed to declare support the extension. You can see the
first inklings of this when the Tree View
Protocol was
introduced here in this
commit.
This then continued to be further expanded as we introduced more extensions.
As it became easier for various clients to set this, we slowly started to
migrate other options that could
only be previously set via server properties to
ClientCapabilities.experimental. So settings like which format you'd like the
Doctor to return could now be set directly by the client without need to
bootstrap the server with a specific property. This allowed for much easier
configuration than was previously had.
InitializationOptions
Once it was clear that configuring Metals via the client was desirable, a closer
look was taken at InitializationOptions that can be passed in during the
initialize
request. Since any value is able to be passed in this way, a decision was made
to fully migrate all the possible settings that were previously set as server
properties (except a select few that we'll touch on later), and also move all
the of settings that could be set under experimental to
InitializationOptions as well. This ultimately allows for clients to fully
configured Metals via InitializationOptions without the need to set any server
properties. In theory this also meant that you could not use the same Metals
executable for VS Code, Vim, or Emacs since the server is fully being configured
by the client itself. The current settings that can be passed in and their
defaults are explained in detail here on the
website,
but the interface is as follows:
You'll notice that this allows for a much finer grained configuration if the
client chooses to set certain values. Everything from whether or not the Scala
Presentation Compiler should populate the SignatureHelp.documentation to
whether or not the editor supports opening a new window after using the
metals.new-scala-project command can now be easily configured. Fully
configuring Metals through InitializationOptions is now the recommended way to
configure Metals.
Are there still server properties?
While all of the old server properties still exist for Metals, it's no longer
recommended to use them to configure Metals. However, there are still a few
server properties that remain only server properties since they are not meant to
be widely used, and aren't exactly recommended to use for the average user. You
can see an up to date list of these here on the
website
and what functionality they provide.
Conclusion
As of Metals 0.9.2 it's fully possibly for all clients to use a default
bootstrapped Metals that can fully be configured via InitializationOptions.
There is a freshly updated Integrating a new
editor section on
the website to help explain how to exactly configure a client for usage with
Metals. As always, don't hesitate to reach out on any of the various channels
located in the footer or submit an issue to either improve documentation or to
log a bug. Also as a reminder, there is a separate repo for
metals-feature-requests.
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.
Previously, when either a build tool was chosen for a workspace or the build
import notification was dismissed the only way to revert that choice was to
delete the .metals directory. In this release we added two different ways to
reset it:
via a new button available in the doctor (Visual Studio Code):
using a new command metals.reset-choice (other editors):
Miscellaneous improvements
Named parameters completions fixed to work in cases where the method was
defined later in the class.
Add option to not add the Bloop plugin in Gradle builds. This might be useful
if you already define Bloop plugin in your workspace, otherwise it's not
recommended.
Find all templates from the giter8 wiki page for the New Project Provider
Contributors
Big thanks to everybody who contributed to this release or reported an issue!
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.
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.
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
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
https://ammonite.io.
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:
$ivy.`organisation::artifact:version`
For example:
$ivy.`com.lihaoyi::scalatags:0.9.0`
:: 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
https://github.com/scala/scala-seed.g8.
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 build.sc, but the build.sc 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
Contributors
Big thanks to everybody who contributed to this release or reported an issue!
We are happy to announce the release of Metals v0.9.0, codename "Lithium", which
main focus is introducing support for Scala 3 starting with versions 0.23.0 and
0.24.0-RC1. We also added support for Scala 2.13.2 and a number of other useful
improvements.
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.
Automatically add '+' on newline when inside a string
New Code action: "Import all missing symbols"
Basic Scala 3 support
For a couple of the last months we have been working on making Metals work with
the Dotty compiler, which will become the new Scala 3. This effort included
contributions to Metals, Bloop as well as to Dotty. Thanks to the great help
from the Dotty compiler team, we now have an option to generate semanticDB files
used for our internal indexes, which allowed some features to work without any
changes to the core code. It is also important to mention that without
jvican and his Bloop project, which already
supports Scala 3, all this would have taken a much longer time.
That said, there are some issues that are lacking in the Scala 3 support that
are available for 2.x versions. Most notably, we are still missing all of the
more advanced completions, filtering and sorting of completion items or auto
imports. There are also some possible issues connected to optional braces and
top level methods features. In the upcoming months we are planning to address
most of these issues and implement the lacking features.
The first supported versions will be 0.23.0 and 0.24.0-RC1, which are the
latest stable and the latest release candidate respectably. We plan to always
support the latest stable and release candidate until there is a more stable
release cycle for Scala 3.
Please do report any issues you encounter, especially connected to some new
Scala 3 features, which will be an immense help to the team.
Improvements related to Bloop/Metals integration
There have been multiple reported issues in the last weeks about hanging
compilation, which can make the Metals workspace hard to use. Our top priority
has been figuring out all the possible issues both in Metals as well as in
Bloop. Thanks to some fixes done by jvican, and
some work on the Metals side on the Bloop integration we're hopeful that some of
the issues are becoming less frequent. These fixes are included in this release.
We also reworked the Metals tree view to highlight some commands that a user can
use to fix their workspace as well as added two new commands:
Clean compile workspace - clean compile the whole workspace - might be
needed in case of broken compiler caches.
Restart Bloop server - restart the Bloop build server, which should help
with the cases where compilation would hang.
Even if those commands help, do not hesitate to report any issues. We are also
monitoring the situation ourselves and investigating all problems encountered.
Automatically add '+' on newline inside a string
The Metals team was recently joined by mlachkar,
an engineer from the Scala Center, who already contributed a number of features
and bug fixes to the project. Thanks to her, we can now easily enter a newline
inside a single line string and that string will be correctly split with an
additional +.
Code action to import all missing symbols
Previously, it was only available to import one symbol at a time in case of
missing imports. Thanks to colineto we now have
the ability to import everything in bulk for every unambiguous import available.
Unambiguous in this case meaning that there is only one possible import to
choose from.
Miscellaneous improvements
Added an option to ignore .scalafmt.conf creation message.
Fixed hanging while debugging if workspace had errors.
Fixed issue with folding in non 2.12.11 workspaces.
Turn off "Go to parent" code lenses by default due to performance problems in
large workspaces.
Fixed false parsing errors in 2.13.x workspaces.
Added date string to metals logs.
Fixed issue with additional src directories being created automatically.
Fixed "Go to implementation" to work with local aliases.
Fixed auto-import issue in package objects.
Contributors
Big thanks to everybody who contributed to this release! We had a lot of new
contributors doing some really exemplary work.
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.
Metals will now calculate if any definition of a method in the current file
overrides another method, in which case it will show a new lens next to the
method's position. Once clicked, the user will be able to go to the super
method. Lenses also link to methods in external dependencies and are displayed
in files from libraries. For this new feature to work make sure that you enable
code lenses in your client.
If they are found to be disturbing your workflow they can be easily disabled via
the metals.superMethodLensesEnabled configuration option - they are enabled by
default. For example in Visual Studio Code:
These new lenses should be quick to calculate but if you notice significant
slowdown you can also disable them, since when disabled they are not only not
displayed but also not calculated at all.
There is also an exposed server command goto-super-method that can be mapped
and used through shortcut in Visual Studio Code.
It is possible to also navigate the whole inheritance hierachy at once using the
new super-method-hierarchy command.
This new command can be invoked on a method definition. It calculates super
method hierarchy and if more than one position is found it displays a quickPick
window (same as the new scala file feature) which displays all super methods and
allows a user to select one and jump to its definition.
As an example in Visual Studio Code it can be bound to a shortcut this way:
Thanks to kpbochenek from VirtusLab for this
new feature!
Support for 'launch.json'
Previously, it was only possible to launch main classes or tests via code lenses
that would appear above a particular class. Now, we add a way for a user to be
able specify the name of the the class or test to run. We will then
automatically try to detect the build target, which that class/test belongs to
and run it. In this release, we also add a way to specify the main class
arguments.
While this will be primarily useful for the Visual Studio Code Metals extension,
it will also make it easier for other editors that support the Debug Adapter
Protocol. To obtain the uri needed for starting a debug session users can now
execute the debug-adapter-start command with params:
buildTarget is an optional parameter, which might be useful if there are
identically named classes in different modules. A uri will be returned that can
be used by the DAP client.
More information about adding support for debugging is available
here.
This awesome new feature was contributed by
alekseiAlefirov from VirtusLab.
New 'Create new symbol...' code action
Previously we would propose to import a symbol (if available) in response to
"missing symbol" errors. Now, thanks to gabro, we
also propose to create a new class, case class, trait or object.
This might be useful when sketching out a domain model and should improve user
experience for fast prototyping.
Miscellaneous improvements
package is no longer added on imports from package objects
if user right clicks on a file in Visual Studio Code the option for
New Scala file also shows now the same as for directories
a multiline string can now be formatted exclusively when using
format selection on that string
added in ... to signify truncation in worksheets
fixed hover on Scala App trait and several other cases that showed up on Scala
Play projects
messages about upgrading Scala versions are now more valid to the user
references in a file are sorted before showing them
better cursor position when creating new files using the New Scala file
command
added "case class" option in NewFilesProvider
Contributors
Big thanks to everybody who contributed to this release!
