Skip to content

Releases: VirtusLab/scala-cli

v0.1.8

14 Jun 11:57
05de912
Compare
Choose a tag to compare

--list-main-classes option for the run command

You can pass the option --list-main-classes to the run command to list all the available main classes, including
scripts.

$ scala-cli . --list-main-classes
Hello scripts.AnotherScript_sc scripts.Script_sc

Added in #1095 by @Gedochao

Add config command

The config sub-command allows to get and set various configuration values, intended for use by
other Scala CLI sub-commands.

This feature has been added in preparation for the publish command, stay tuned for future announcements.

Added in #1056 by @alexarchambault

Prioritise non-script main classes

When trying to run a directory containing scripts and just a single non-script main class, the non-script main class
will now be prioritised and run by default.

$ scala-cli .
Running Hello. Also detected script main classes: scripts.AnotherScript_sc, scripts.Script_sc
You can run any one of them by passing option --main-class, i.e. --main-class scripts.AnotherScript_sc
All available main classes can always be listed by passing option --list-main-classes
Hello world

Changed in #1095 by @Gedochao

Important bugfixes

Accept latest Scala versions despite stale Scala version listings in cache

Scala CLI uses version listings from Maven Central to check if a Scala version is valid. When new Scala versions are
released, users could sometimes have stale version listings in their Coursier cache for a short period of time (the
Coursier cache TTL, which is 24 hours by default). This prevented these users to use new Scala versions during that
time.
To work around that, Scala CLI now tries to re-download version listings when they don't have the requested Scala
version.
This addresses #1090

Fixed in #1096 by @lwronski

Bloop now uses JAVA_HOME by default

Bloop should now pick up the JDK available in JAVA_HOME. It was formerly necessary to pass --bloop-jvm system
explicitly. This addresses #1102

Fixed in #1084 by @lwronski

The -coverage-out option now accepts relative paths

Scala CLI now correctly processes relative paths when passed to the -coverage-out option. Formerly,
the scoverage.coverage file would not be properly generated when a relative path was passed.
This addresses #1072

Fixed in #1080 by @lwronski

Other changes

Documentation PRs

Fixes

  • Add suffix to project name which contains virtual files by @lwronski
    in #1070

Build and internal changes

Full Changelog: v0.1.7...v0.1.8

v0.1.7

06 Jun 14:35
22f5c86
Compare
Choose a tag to compare

Support for printing help from scala compiler

Help from the scala compiler can now be printed without passing any sources:

$ scala-cli --scalac-help
  Usage: scalac <options> <source files>
    where possible standard options include:
    -Dproperty=value      Pass -Dproperty=value directly to the runtime system.
    -J<flag>              Pass <flag> directly to the runtime system.
  ...

Other scalac print help options (like -X, -Xshow-phases, -Vphases, etc.) are supported as well.

$ scala-cli -Xshow-phases
...
Possible advanced options include:
-Xcheck-macros              Check some invariants of macro generated code while
...

Added in #1052 by @Gedochao

Scala CLI is built using mill-scala-cli Mill plugin

We now rely on mill-scala-cli Mill plugin, which allows compiling Scala modules with Scala CLI rather than with Mill's ZincWorker.
To see more go to mill-scala-cli and try it in your project.

Added in #1042 by @alexarchambault

Add default-file command

The default-file sub-command provides sensible default content for files such as .gitignore or for GitHub actions workflows, for Scala CLI projects.

$ scala-cli default-file --write .gitignore .github/workflows/ci.yml
 Wrote .gitignore
 Wrote .github/workflows/ci.yml

To see more go to default-file section in documentation.

Added in #1027 by @alexarchambault

Enhancements

Setup-ide use symlink if target is the same as current launcher

The path to Scala CLI points to the symlink if the launcher path is the same as the canonical path which targets the symlink.

Changed in #1050 by @lwronski

Better messages in doctor

The doctor command now has a better suggestion to update scala-cli.

Changed in #1069 by @lwronski

In progress

More publishing-related features

Interactive mode

Other changes

Documentation PRs

Updates

Build and internal changes

Contributors

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

According to git shortlog -sn --no-merges v0.1.6...v0.1.7 these are:

   34  Alexandre Archambault
    12  Piotr Chabelski
     7  Łukasz Wroński

Full Changelog: v0.1.6...v0.1.7

v0.1.6

23 May 15:06
df9dc66
Compare
Choose a tag to compare

Add doc command

Scala CLI now has a doc sub-command, that generates javadoc / scaladoc. Use like

$ scala-cli doc . --output scala-doc

You can then open scala-doc/index.html in your browser.

Added in #991 by @lwronski

Accept Java code via standard input

Java code can now be piped to Scala CLI:

$ cat Foo.java
public class Foo {
    public static void main(String[] args) {
        System.out.println("Hello from Scala CLI");
    }
}
$ cat Foo.java | scala-cli _.java
Hello from Scala CLI

Added in #956 by @Gedochao

Enhancements

Revolver mode alias

The --revolver option of the run sub-command now has a --restart alias. This option interrupts any running application in watch mode upon source changes, rather than waiting for it to exit.

Added in #976 by @lwronski

Better messages in export

The export command now has more and better output.

Changed in #978 by @Gedochao

Better pure Java projects support

When compiling / running pure Java projects, Scala CLI won't download any more Scala test bridges and Scala version listings.

Changed in #982 by @alexarchambault

Suggest users to run scala-cli bloop output if starting the Bloop server fails

When Scala CLI can't start the Bloop server (that is, its compilation server), it now suggests to run scala-cli bloop output, which should have more details about what failed.

Changed in #1002 by @alexarchambault

Allow users to pick a main class via an interactive prompt

When passed -i or --interactive, if several main classes are detected, Scala CLI now offers users to interactively pick a main class, via a prompt, rather than exiting.

Added in #1016 by @lwronski

Fixes

Fix possible cause of abrupt Bloop server disconnection upon startup

  • Use snailgun fork, allowing to slightly rework nailgun input stream handling by @alexarchambault in #944

Fix handling of UTF-8 characters in file names on Linux

Fix Scala.js and Scala Native help messages

Add workaround for zip CRC32 errors on Arch Linux

Use 0 TTL when getting Scala nightly versions

  • Set ttl to 0.second for cache with scala 2 nightlies by @lwronski in #1006

In progress

More publishing-related features

Other changes

Documentation PRs

  • Use absolute path for loading images/gifs by @lwronski in #874
  • Update directective instruction for tests by @amaalali in #918
  • Update using-directives.md by @romanowski in #925
  • Back port of documentation changes to main by @github-actions in #969
  • java deps directive by @swuecho in #974
  • Back port of documentation changes to main by @github-actions in #977
  • Back port of documentation changes to main by @github-actions in #987
  • Update main-class name for scala-cli 0.1.5 by @lolgab in #990
  • Fix typo in education page by @szymon-rd in #1013

Updates

Build and internal changes

New Contributors

Full Changelog: v0.1.5...v0.1.6

v0.1.5

04 May 09:57
a86dd28
Compare
Choose a tag to compare

The package command output name now follows the actual main class name

The default output name of the package command will now follow the actual compiled main class name, while it formerly followed the inferred class name coming from the first source file passed as argument, where applicable.

In other words, for the following 2 sources:

case class SomeCaseClass(value: String)
object Main extends App {
  val smth = SomeCaseClass(value = "Hello")
  println(smth.value)
}

Running package without explicit --output:

scala-cli package SomeCaseClass.scala ActualMainClass.scala

For Scala CLI v0.1.4 and before would the output file name would default to SomeCaseClass, while as of v0.1.5 it will now fallback to Main.

If you rely on the package command without explicitly passing the --output parameter, the actual output file name may now be different, depending on the passed sources.
Please make sure this does not break any automation in your scripts when upgrading Scala CLI to this version.

This change was added by @Gedochao in #943.

Scala CLI is built using Scala 3

We now rely on Scala 3 (3.1.2 as of this release) as the default internal Scala version used to build the project. We still compile some modules (which were using macros heavily) with Scala 2.13. However, the fact that we can do so shows that migration from Scala 2 to Scala 3 can be done by isolating macros.

This change was added by @romanowski in #913.

Pure Java projects support

Projects consisting only of Java sources are now handled more consistently by Scala CLI. In particular, the Scala library JAR isn't added any more in the class path, and no Scala JARs are downloaded upfront.

This was changed in #940 by @alexarchambault.

Notable PRs

  • Fix compute nightly version Scala 2 by @lwronski in #908
  • Switch to Scala 3 by default by @romanowski in #913
  • Ensure a main class element is findable in Scala code passed by stdin by @Gedochao in #933
  • Refactor the usage of default main class override to only apply to on-disk Scripts by @Gedochao in #943
  • Define valid package type for Scala.js and Scala Native by @lwronski in #941
  • Add pure Java projects support by @alexarchambault in #940

Documentation PRs

  • Add more details in the release procedure docs by @Gedochao in #920

Other merged PRs

Contributors

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

According to git shortlog -sn --no-merges v0.1.4...v0.1.5 these are:

    37  Alexandre Archambault
    16  Piotr Chabelski
     8  Scala Steward
     6  Łukasz Wroński
     4  github-actions[bot]
     1  Krzysztof Romanowski

Full Changelog: v0.1.4...v0.1.5

v0.1.4

19 Apr 12:50
65e47cf
Compare
Choose a tag to compare

New Contributors

Thank you!

Improved support for IDEA IntelliJ

As of v0.1.4 using Scala CLI with IDEA IntelliJ is no longer discouraged and should be on par with metals.
If IDEA IntelliJ is your IDE of choice, but you haven't been using it alongside Scala CLI due to its former instability, make sure to give it a try!

Also, if you nonetheless run into any issues when working with IntelliJ, be sure to report it to us.

Scala CLI now supports BSP workspace/reload

It is now possible to reload the workspace with BSP. This effectively means that if you are using an IDE with Scala CLI, any changes to your builds (including i.e. source directories, dependencies or passed options) introduced by subsequent runs of Scala CLI setup-ide, run and compile commands should be picked up by your IDE automatically.

This should particularly improve the experience of using Scala CLI with IDEA IntelliJ.

This feature was added by @Gedochao in #858, #863 and #886.

Scala CLI now supports passing a JAR url as a fallback fetching method

You can now add a url=https://... param to a dependency to use the url as a fallback fetching method. The url will be used if the JAR can't be fetched from Maven Central.

Example usage:

scala-cli run --dependency "tabby:tabby:0.2.3,url=https://github.com/bjornregnell/tabby/releases/download/v0.2.3/tabby_3-0.2.3.jar" UsingRemoteJar.scala

or with a using directive:

//> using lib "tabby:tabby:0.2.3,url=https://github.com/bjornregnell/tabby/releases/download/v0.2.3/tabby_3-0.2.3.jar"
import tabby.Grid

object UsingRemoteJar extends App {
  println(Grid("a", "b", "c")(1, 2, 3))
}

This feature was added by @Gedochao in #875.

Scala CLI now supports smallmodulesfor module split style for Scala.js

Scala.js option --js-module-split-style now supports a new module split style with smallmodulesfor (in addition to previously supported fewestmodules and smallestmodules). To define packages use --js-small-module-for-package.

Example usage with directives:

//> using jsModuleSplitStyleStr "smallmodulesfor"
//> using jsSmallModuleForPackage "com.example.test", "com.example.example""

or straight from the CLI:

scala-cli package --js-module-split-style smallestmodulesfor --js-small-module-for-package "com.example.test" --js-small-module-for-package "com.example.example"

This feature was added by @lwronski in #894.

It is now possible to skip the --cli-scala-version parameter when running an old Scala CLI version

When running an old (pre-migration to Scala 2.13) Scala CLI version (i.e. v0.1.1) it was formerly necessary to specify the Scala version --cli-scala-version explicitly (to make it build correctly with Scala 2.12).
Thus, it is now possible to just run:

scala-cli --cli-version 0.1.1  about

This feature was added by @lwronski in #872.

Scala CLI Bloop server now ignores SIGINT

From now on when the mill or scala-cli invocation that starts the Bloop server gets interrupted by Ctrl-C (to stop a watch mode, for example), the Bloop server running in the background will ignore the interruption and just keep on running.

This feature was added in #851.

Bloop server output is kept in a file

From now on Scala CLI keeps its Bloop server output in a file.
The output can be obtained through the bloop output command:

scala-cli bloop output

This might be useful when debugging problems with Bloop (for example, if the server fails to start or times out).

This feature was added in #853.

Notable PRs

Documentation PRs

Other merged PRs

Contributors

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

According to git shortlog -sn --no-merges v0.1.3...v0.1.4 these are:

25  Alexandre Archambault
15  Scala Steward
12  Piotr Chabelski
 9  Łukasz Wroński
 4  Krzysztof Romanowski
 3  Brian J Brennan
 2  github-actions[bot]
 1  dependabot[bot]
 1  zmerr
 1  Alexander Gehrke

Full Changelog: v0.1.3...v0.1.4

v0.1.3

04 Apr 12:34
d469bc1
Compare
Choose a tag to compare

New Contributors

Thank you!

Scala CLI can run nightly versions of Scala 2.12, 2.13 and 3.x

Since 0.1.3 it is possible to use the latest nightly version of Scala compiler with the syntax 2.12.nightly, 2.13.nightly and 3.x.nightly.

For compiling with the latest Scala 2.12 nightly build:

scala-cli Hello.scala -S 2.12.nightly

For compiling with the latest specific binary version of Scala 3 nightly build:

scala-cli Hello.scala -S 3.1.nightly
scala-cli Hello.scala -S 3.0.nightly

This feature was added by @zmerr in #736 and #788

Revolver mode

--revolver mode runs your application in the background and automatically restarts it upon any change:

 scala-cli run Hello.scala --revolver
 # Hello
 # Watching sources, press Ctrl+C to exit.
 # Compiling project (Scala 3.1.1, JVM)
 # Compiled project (Scala 3.1.1, JVM)
 # Hello World
 # Watching sources, press Ctrl+C to exit.

This feature was added by @lwronski in #747

Support Scala.js linking on Windows

Scala CLI now supports Scala.js linking on Windows, so it allows to build and run Node.js applications on this OS (changed in #676).

Native image packaging

Passing --native-image to the package sub-command generates native executables applications using GraalVM native images. This feature may not work with Scala 3 but Scala CLI team is working to fix it soon (changed in #773).

scala-cli package Hello.scala -o hello --native-image

Build Scala CLI with Scala 2.13

From now on Scala CLI is built with Scala 2.13. It is a first step in order to migrate to Scala 3, stay tuned (changed in #649).

Scaladoc packaging

Passing --doc to the package sub-command generates a scaladoc JARs. These follow the same format as the scaladoc JARs of libraries published to Maven Central. This is another step for adding support for a publish command, which should be announced in the next release (this feature was added in #774).

scala-cli package Hello.scala -o hello --doc

Experimental

New publish command

publish command was added to Scala CLI, but it is still until development and requires some additional testing. Publishing your library will be easier than before, so stay tuned to official announcement this feature (this feature was added in #707).

Proxy auth mechanism

Authenticated proxies can now be configured in Scala CLI. Note that this feature should also work in the Scala CLI native launchers, which is an improvement over how it works in the coursier CLI (there, it works for coursier run from the JVM, not with the coursier native launchers).

To setup authenticated proxy credentials, we recommend setting 8 Java properties, like

$ scala-cli \
  -Dhttp.proxyHost=my-proxy.com -Dhttp..proxyPort=8888 -Dhttp.proxyUser=johndoe -Dhttp.proxyPassword=1234 \
  -Dhttps.proxyHost=my-proxy.com -Dhttps..proxyPort=8888 -Dhttps.proxyUser=johndoe -Dhttps.proxyPassword=1234

(You should change the property values to the ones of your proxy.)

The way these proxies are configured is a bit cumbersome, and is likely to change in the near future.

(changed in #768)

Notable changes

Merged PR

Documentation changes

Read more

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