Skip to content

v0.1.0
Compare
Choose a tag to compare
@romanowski romanowski released this 27 Jan 15:39
v0.1.0
1174672
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

This is the first release that contains breaking changes (within using directives) since the project became public. We want to thank our users for all the warm reception we see over various channels, all bug reports and suggestions. With such support, developing Scala CLI is a real pleasure.

New Contributors

  • @jchyb become a member of the core team, with focus on Scala Native and scripting
  • @mpkocher made their first contribution in #514
  • @lolgab made their first contribution in #581

Thank you!

New syntax for using directives

This release brings a lot of changes within using directives.

Firstly, our internal parser for using directives was retired in favor of using_directives library. The using directives grammar has been cleaned up. From this release, using directives values need to be a valid Scala primitives namely numbers, booleans or strings. @pikinier20 has concluded that effort in #364

We have changed the syntax further, namely:

  • using directives in plain comments (// using foo bar and /* using foo bar */) is deprecated
  • annotation syntax for using directives is deprecated (@using)
  • we are introducing special comments for using directives using >: //> using foo bar and /*> using foo bar */

Old syntaxes will still work in 0.1.x releases but will result in warnings like this one:

[warn] ./a.scala:2:1: This using directive is ignored. Using directive using plain comments are deprecated. Please use a special comment syntax: '//> ...' or '/*> ... */'
[warn] // using options "-Xasync"
[warn] ^^^

This change was introduced by @romanowski in #546.

Scala CLI now uses its own bloop instance

Using a global bloop server is not ideal, since it limits our control on used options or JVM. In the past, we've also had some conflicts with Metals managing that server. Bloop has potential security vulnerabilities when using Scala CLI within multi-user environments and for that we wanted to switch our communication with bloop so it use named pipes rather than sockets. That is why we decided that Scala CLI should use its own dedicated bloop sever that is fully controlled by us.

@alexarchambault made the required changes in bloop that lives in our fork until they are merged upstream (we do not plan to maintain that fork for long). Also, we decided to run our bloop on Java 17. That work resulted in following PRs: #469, #508, #507 and #529.

Having a dedicated bloop sever increased consumed resources, mainly the memory. To reduce that impact @tpasternak analyzed (#515) usage of different garbage collectors so our bloop server can release memory back to OS when unused. ZGC offers the best performance so it was used by default in our bloop server in #553.

Redesign of Scala Native support

In order to decouple Scala CLI from specific versions of Scala Native, Scala Native CLI was created and used within Scala CLI to build Scala Native applications. Scala CLI can now easily support multiple versions of Scala Native, including future releases without a need to release Scala CLI. Scala CLI supports Scala Native 0.4.3 so it is possible to use Scala Native with Scala 3.

@jchyb co-created Scala Native CLI and introduced it into Scala CLI in: #527, #449 and #554

Scala CLI can be run with specific version or using latest snapshot

Since 0.1.0 it is possible to specify in command line a specific version of Scala CLI. It is also possible to use the latest snapshot. It will use the JVM-based launcher and this will come with overhead needed to start JVM for each scala-cli usage.

This feature is also compatible with SheBang header in Scala Script:

#!/usr/bin/env -S scala-cli --cli-version 0.0.9+131-gf0ab5c40-SNAPSHOT shebang
println(args(1))

This feature was added by @lwronski in #548 .

Improve handling of automatically-resolved versions

Until now, Scala CLI was using latest released Scala version that matches the input provided by users (e.g. 3 or 2.12). As 2.13.7 showed us, small changes in the internals may break bloop or other parts of Scala CLI and with that break overnight applications or CIs. To avoid such a problem, @lwronski in #456 and #563 added support for predefined list of Scala versions per wildcard, defined in a file in a separate Scala CLI-controlled repository. We plan to update that list with all new Scala version that would work with Scala CLI given Scala CLI version.

This feature only applies to automatically-resolved versions so it is possible to provide any version of Scala even if it is not verified by the team.

Rename our build directory to .scala-build

We were using a directory called .scala to store all build-related artifacts (.class files, bloop details etc.) and it was causing some confusion in Metals and messing up with searching for Scala sources in scripts. @alexarchambault changed that directory to .scala-build in #573

We are also checking if the current user can access build directory and in case not we fall back to a global build directory within the user's home directory. This change allows Scala CLI to be run as a different user/root using sudo and similar commands.

Scala CLI is used to verify code snippets in our repository

This is not related strictly to this release, but from some time (#562) we are using scala-cli to verify the snippets in reported issues using scala-cli based github action created by @lwronski

Improve handling of JVMs and Java sources

This release improves the way Scala CLI handles JVMs and Java sources so we decided to group all those issues together. Even though Scala CLI has Scala in its name, it can be used to build Java-only projects.

The list is as follow:

Other changes:

Bugfixes

Internal improvements

Updates

Full Changelog: v0.0.9...v0.1.0

Contributors

mpkocher, tpasternak, and 9 other contributors
Assets 13
Loading