Skip to content

Releases: VirtusLab/scala-cli

v0.1.2

22 Feb 09:56
784a7af
Compare
Choose a tag to compare

This release focuses on stability.

The last release of Scala CLI 0.1.1 introduced some regressions and we have decided not to announce it. This release notes is composed of both 0.1.1 and 0.1.2 releases.

New Contributors

Thank you!

Scala CLI now uses Java 17

From now, Scala CLI uses by default Java 17 to compile and run your scala code (changed by in #669)

Redesign Compile command

Until now, Scala CLI compiles the main and test scope if you run the following commands: run, package, compile and repl.

Since 0.1.2 the compile command is compiling only the main scope by default. If you want to compile also test scope, you should pass --test flag to compile command:

scala-cli compile --test [args]

package,repl and run commands by default compile only the main scope. This change was introduced in #638 by @lwronski.

Scala CLI can run nightly versions of Scala 2 and 3

Since 0.1.2 it is possible to use the latest nightly version of Scala compiler with the syntax 2.nightly and 3.nightly.

For compiling with the latest Scala 2 nightly build:

scala-cli Hello.scala -S 2.nightly

For compiling with the latest Scala 3 nightly build:

scala-cli Hello.scala -S 3.nightly

For compiling with a specific nightly build for Scala 2, you have to pass the full version:

scala-cli Hello.scala -S 2.13.9-bin-4505094 

It is also possible to use this syntax in using directives:

//> using scala "2.nightly"

This feature was added by @zmerr in #677.

Override using directives options

This release adds support to override scalac, java, and dependency options of using directives with CLI counterparts. Only specific values (a given dependency or java or scala option) are overridden, and the rest of the options are concatenated. In the following example:

$ cat Hello.scala
//> using lib "org.scalameta::munit::1.0.0-M1"
//> using lib "com.lihaoyi::os-lib:0.8.1"

$ scala-cli Hello.scala  --dependency "org.scalameta::munit::0.7.29" --dependency "io.spray::spray-http:1.3.4"

Scala CLI uses version 1.0.0-M1 of munit, along with os-lib and spray-http.

This feature allows overriding (downgrade) a value/dependency without modifying the source file (or when used with e.g. gists)

Thanks to @jchyb in #612

Suport for SDK

Scala CLI will be available on SDKMAN. From now, Scala CLI generates packages that are supported by SDKMAN.

This change was introduced in #609 .

Experimental support for using directives in Java files

in #639, @ghostbuster91 has implemented initial support for placing using directives within .java files as a part of Scala 3 issue spree framework with help from @mtk and @romanowski. The feature is still experimental and actual directives that will be supported and other details are subject to change in upcoming releases.

Notable changes

Merged PR

Documentation changes

Contributors

Thank you to all the contributors who made this release possible 🎉

According to git shortlog -sn --no-merges v0.1.0...v0.1.2 these are:

37  Alexandre Archambault
25  zmerr
16  Łukasz Wroński
9  Krzysztof Romanowski
5  ghostbuster91
4  Jan Chyb
1  Simon Parten
1  Kasper Kondzielski

Full Changelog: v0.1.0...v0.1.2

v0.1.1

10 Feb 09:39
0d5d1d5
Compare
Choose a tag to compare

This release focuses on stability.

Override using directives options

This release adds support to override scalac, java, and dependency options of using directives with CLI counterparts. Only specific values (a given dependency or java or scala option) are overridden, and the rest of the options are concatenated. In the following example:

$ cat Hello.scala
//> using lib "org.scalameta::munit::1.0.0-M1"
//> using lib "com.lihaoyi::os-lib:0.8.1"

$ scala-cli Hello.scala  --dependency "org.scalameta::munit::0.7.29" --dependency "io.spray::spray-http:1.3.4"

Scala CLI uses version 1.0.0-M1 of munit, along with os-lib and spray-http.

This feature allows overriding (downgrade) a value/dependency without modifying the source file (or when used with e.g. gists)

Thanks to @jchyb in #612

Suport for SDK

Scala CLI will be available on SDKMAN soon. From now on, Scala CLI generates packages that are supported by SDKMAN.

This change was introduced @lwronski in #609 .

New Contributors

Thank you!

Notable changes

  • Provide proper logger for using directives plus Tweaking by @alexarchambault in #618
  • Generate only one build target for main and test scope by @lwronski in #550
  • Fix #588: fmt --check not being passed to scalafmt by @jchyb in #600
  • Fix project import in Intellij. Support for Intellij still depends on project structure and in many cases may not work regardless of this fix by @romanowski in #608

Merged PRs

Documentation changes

Contributors

Thank you to all the contributors who made this release possible 🎉

According to git shortlog -sn --no-merges v0.1.0...v0.1.1 these are:

15  Alexandre Archambault
12  Łukasz Wroński
7  Krzysztof Romanowski
5  zmerr
3  Jan Chyb
1  Simon Parten

Full Changelog: v0.1.0...v0.1.1

v0.1.0

27 Jan 15:39
1174672
Compare
Choose a tag to compare

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

Read more

v0.0.9

02 Dec 18:18
26feee8
Compare
Choose a tag to compare

This release focuses on stability.

New scala-cli shebang command

Change the way how scala-cli parses it's command-line arguments in order to be compatibility with shebang scripts. To see more go to shebang section in documentation.

Added in #410, thanks to @tpasternak .

Zsh/Bash option completions

Fixed in #423, thanks to @lwronski to add escaping backticks in case-app.

Resources directory

Now, scala-cli accepts resource directory for Github Gists. Added in #415 . We change name of directive to specify resource directory from resource -> resourceDir #412.

Shebang in Scala file.

We support shebang header in Scala file, added in #435.

Update

To update scala-cli use your package manager or, if you used an installation script before, run it again - curl -sSLf https://virtuslab.github.io/scala-cli-packages/scala-setup.sh | sh.

Scala CLI is still far from being stable however within three realise Scala CLI is mostly feature-complete for 1.0 release.

Notable changes

Merged PRs

Documentation changes

New Contributors

Contributors

Thank you to all the contributors who made this release possible 🎉

According to git shortlog -sn --no-merges v0.0.8..v0.0.9 these are:

21  Scala Steward
13  Tomasz Pasternak
8  Łukasz Wroński
6  Alexandre Archambault
6  Krzysztof Romanowski
3  dependabot[bot]
3  Chris Kipp
3  asjad02
1  Tim Nielens
1  Asjad Baig
1  gh-actions
1  Johan Walters
1  Filip Zybała
1  Alvin Alexander
1  Marcin Aman

Full Changelog: v0.0.8...v0.0.9

0.0.8

08 Nov 14:52
f40f126
Compare
Choose a tag to compare

This release focuses on stability and support for Metals (mainly in Visual Studio Code).

To update scala-cli use your package manager or, if you used an installation script before, run it again - curl -sSLf https://virtuslab.github.io/scala-cli-packages/scala-setup.sh | sh

Scala CLI is still far from being stable however within three realise Scala CLI is mostly feature-complete for 1.0 release.

Notable changes

What's Changed

Documentation changes

New Contributors

Contributors

Thank you to all the contributors who made this release possible 🎉

According to git shortlog -sn --no-merges v0.0.7..v0.0.8 these are:

25  Łukasz Wroński
25  Krzysztof Romanowski
8  Tomasz Pasternak
4  Chris Kipp
4  Bjorn Regnell
4  Alvin Alexander
3  Marcin Aman
3  Jakub Kozłowski
2  Seth Tisue
2  Kacper Korban
1  Alexandre Archambault
1  Naoki Takezoe

Full Changelog: v0.0.7...v0.0.8

v0.0.7 - first usable version

20 Oct 11:17
aa3bddb
Compare
Choose a tag to compare

This is the first version of Scala CLI that can be tested by the users.

Scala CLI is still far from being stable however within three realise Scala CLI is mostly feature-complete for 1.0 release.

v0.0.6

15 Oct 16:36
0c482f1
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.0.5...v0.0.6

v0.0.5

12 Oct 14:12
036379a
Compare
Choose a tag to compare

What's Changed

New Contributors

Full Changelog: v0.0.4...v0.0.5

v0.0.4

29 Sep 14:33
Compare
Choose a tag to compare

.

v0.0.3

27 Sep 09:49
Compare
Choose a tag to compare

.