Skip to content

Releases: VirtusLab/scala-cli

v1.1.2

17 Jan 09:06
0421cd9
Compare
Choose a tag to compare

Support for Scala.js 1.15.0

This version adds Scala CLI support for Scala.js 1.15.0.
Added by @scala-steward in #2672 & @Gedochao in VirtusLab/scala-js-cli#43.

Fixes

  • Fix repeatable compiler options handling from the command line by @Gedochao in #2666
  • Fix script wrapper tests & script object wrapper using directive by @Gedochao in #2668
  • Prevent consecutive -language:* options from being ignored by @Gedochao in #2667
  • in FailedToStartServerException advice, include --power by @SethTisue in #2685

Documentation changes

  • Fix test.md by @MaciejG604 in #2679
  • Back port of documentation changes to main by @github-actions in #2681

Build and internal changes

  • Update release procedure steps for v1.1.x by @Gedochao in #2665
  • Tag GitHubTests.create secret as flaky on all Mac tests (including M1) by @Gedochao in #2677

Updates and maintenance

Full Changelog: v1.1.1...v1.1.2

v1.1.1

10 Jan 12:42
3d2a670
Compare
Choose a tag to compare

Deprecate Scala Toolkit latest version in favour of default

Using toolkits with the latest version is now deprecated and will cause a warning.
It will likely be removed completely in a future release.

scala-cli --toolkit latest -e 'println(os.pwd)'
# Using 'latest' for toolkit is deprecated, use 'default' to get more stable behaviour:
#  --toolkit default
# Compiling project (Scala 3.3.1, JVM (17))
# Compiled project (Scala 3.3.1, JVM (17))
# /home

It is now advised to either use an explicit toolkit version or rely on the new default alias.

scala-cli --toolkit default -e 'println(os.pwd)'
# Compiling project (Scala 3.3.1, JVM (17))
# Compiled project (Scala 3.3.1, JVM (17))
# /home

The default version for toolkits is tied to a particular Scala CLI version.
You can check which version is used by referring to Scala CLI help.

scala-cli version                 
# Scala CLI version: 1.1.1
# Scala version (default): 3.3.1
scala-cli run -h|grep toolkit         
#   --toolkit, --with-toolkit version|default  Add toolkit to classPath (not supported in Scala 2.12), 'default' version for Scala toolkit: 0.2.1, 'default' version for typelevel toolkit: 0.1.20

Added by @MaciejG604 in #2622

Enhancements

Fixes

  • Fallback to UTF-8 in setup-ide by @JD557 in #2599
  • Separate Scala REPL classpath from user dependencies by @Gedochao in #2607
  • Prevent resource directories from breaking sources hash by @Gedochao in #2654
  • Fix special handling for the -Xplugin-list compiler option by @Gedochao in #2635
  • Remove superfluous traits by @MaciejG604 in #2618
  • Prevent the toolkit latest deprecation warning from being logged more than once by @Gedochao in #2657

Documentation changes

  • Unify mentions of Java properties and link to the correct section of guides. by @MaciejG604 in #2603
  • Document script wrappers by @MaciejG604 in #2596
  • Shorten titles of cookbooks by @MaciejG604 in #2609
  • Add docs for bloop interaction by @MaciejG604 in #2608
  • Docs/java opts for compiler by @MaciejG604 in #2619
  • Add a subcategories layer for guides & cookbooks by @Gedochao in #2612
  • Merge documentations about proxy setup by @MaciejG604 in #2597
  • Update test framework versions by @mbovel in #2625
  • Back port of documentation changes to main by @github-actions in #2604
  • Back port of documentation changes to main by @github-actions in #2611
  • Back port of documentation changes to main by @github-actions in #2615
  • Back port of documentation changes to main by @github-actions in #2617
  • Back port of documentation changes to main by @github-actions in #2620

Build and internal changes

Updates and maintenance

New Contributors

Full Changelog: v1.1.0...v1.1.1

v1.1.0

29 Nov 16:10
9385014
Compare
Choose a tag to compare

Breaking update to Scala 2 scripts

Keep in mind that it ONLY applies to Scala 2! Scala 3 script wrappers are not affected!

Scala CLI now uses a different kind of script wrappers for Scala 2 by default, which support running background threads.
This has been introduces as an answer to the issue #2470, where a running a script in Scala 2 would end up in a deadlock due to background threads being run.
Also the change makes the Scala 2 scripts run significantly faster, as the code can be optimized due to not residing in the object's initialization clause.

However, the new solution brings some incompatibilities with the old behaviour:

  • main classes are now named the same as the file they are defined in, they do not have the '_sc' suffix anymore, so any calls like:
scala-cli foo.sc bar.sc --main-class foo_sc

should be replaced with

scala-cli foo.sc bar.sc --main-class foo
  • it is impossible to access the contents of a script named main.sc from another script, any references to the script object main will result in a compilation error.
println(main.somethingDefinedInMainScript)

Will result in the following compilation error:

[error] ./foo.sc:2:11
[error] missing argument list for method main in trait App
[error] Unapplied methods are only converted to functions when a function type is expected.
[error] You can make this conversion explicit by writing `main _` or `main(_)` instead of `main`.

When main.sc is passed as argument together with other scripts, a warning will be displayed:

[warn]  Script file named 'main.sc' detected, keep in mind that accessing it from other scripts is impossible due to a clash of `main` symbols

Added by @MaciejG604 in #2556

"Drive relative" paths on Windows

Scala CLI now correctly recognizes "drive relative" paths on Windows, so paths like /foo/bar will be treated as relative from the root of the current drive - e.g. C:\foo\bar.
This allows for compatibility of programs referencing paths with e.g. //> using file /foo/bar with Windows.

Added by @philwalk in #2516

UX improvements

Enhancements

  • Default to publish repository configured for local machine when infering publish.ci.repository by @MaciejG604 in #2571
  • Skip validation for default Scala versions, add build test by @MaciejG604 in #2576

Fixes

Documentation changes

  • Add a doc on Windows anti-malware submission procedure by @Gedochao in #2546
  • Fix list of licenses URL by @JD557 in #2552
  • Fix Windows secrets path in the documentation by @JD557 in #2561
  • Update the pgp-pair section of publish setup docs by @MaciejG604 in #2565
  • Back port of documentation changes to main by @github-actions in #2569
  • Document --python flag by @MaciejG604 in #2574
  • Document publishing process configuration by @MaciejG604 in #2580

Build and internal changes

Updates and maintenance

New Contributors

Full Changelog: v1.0.6...v1.1.0

v1.0.6

09 Nov 13:50
7be704c
Compare
Choose a tag to compare

Scala CLI won't default to the system JVM if it's not supported anymore

If your JAVA_HOME environment variable has been pointing to a JVM that is no longer supported by Scala CLI (so anything below 17, really), you may have run into an error like this one with Scala CLI v1.0.5:

scala-cli --power bloop exit 
# Stopped Bloop server.  
export JAVA_HOME=$(cs java-home --jvm zulu:8)
scala-cli -e 'println(System.getProperty("java.version"))'                
# Starting compilation server
# Error: bloop.rifle.FailedToStartServerExitCodeException: Server failed with exit code 1
# For more details, please see '/var/folders/5n/_ggj7kk93czdt_n0jzrk8s780000gn/T/1343202731019130640/.scala-build/stacktraces/1699527280-9858975811713766588.log'
# Running
#   scala-cli --power bloop output
# might give more details.

This is because we no longer support JVM <17 with Scala CLI v1.0.5, but we still have been defaulting to whatever JVM was defined in JAVA_HOME. As a result, Bloop has been failing to start when running with, say, JAVA_HOME pointing to Java 8.

This is no longer the case. Scala CLI will now automatically download Java 17 for Bloop in such a situation (and still use the JVM from JAVA_HOME for running the code, while Bloop runs on 17).

scala-cli --power bloop exit 
# Stopped Bloop server.  
export JAVA_HOME=$(cs java-home --jvm zulu:8)
scala-cli -e 'println(System.getProperty("java.version"))'                
# Starting compilation server
# Compiling project (Scala 3.3.1, JVM (8))
# Compiled project (Scala 3.3.1, JVM (8))
# 1.8.0_392

Added by @tgodzik in #2508.

Other changes

Fixes

  • Fix --watch failing on invalid PathWatchers.Event & skip wonky tests on Mac CI by @Gedochao in #2515
  • bugfix: Don't try to always get system jvm first by @tgodzik in #2508

Documentation changes

  • Back port of documentation changes to main by @github-actions in #2522
  • add cookbook about Emacs integration by @ag91 in #2506

Build and internal changes

Updates and maintenance

New Contributors

Full Changelog: v1.0.5...v1.0.6

v1.0.5

25 Oct 13:24
ecf3779
Compare
Choose a tag to compare

What's new

Accept --power from anywhere

The --power flag used to be a launcher option, which means it used to only be accepted when passed before the sub-command name. Now, it can be passed anywhere in the command line.

scala-cli --power package --help
scala-cli package --power --help
scala-cli package --help --power

Added by @MaciejG604 in #2399

Offline mode (experimental)

It is now possible to run Scala CLI in offline mode for the cases when you don't want the runner
to make any network requests for whatever reason.
This changes Coursier's cache policy to LocalOnly, preventing it from downloading anything.

scala-cli . --offline

Of course, this means that you will have to have all the dependencies relevant to your build already downloaded and available in your local cache.
Reasonable fallbacks will be used where possible, e.g. the Scala compiler may be used instead of Bloop if Bloop isn't available.

Added by @MaciejG604 in #2404

Shorter install script link

Scala CLI's install script is now available behind a conveniently shorter web address:
https://scala-cli.virtuslab.org/get

Added by @Gedochao in #2450

The fix sub-command (experimental)

The fix sub-command is a new addition to Scala CLI. It allows to scan your project for using directives and extract them into the project.scala file placed in the project root directory.
This allows to easily fix warnings tied to having using directives present in multiple files.

scala-cli fix . --power

Added by @MaciejG604 in #2309

Support for building static & shared libraries with Scala Native (experimental)

You can now use the --native-target option to build Scala Native projects as static or shared libraries.

scala-cli package . --power --native-target static
scala-cli package . --power --native-target dynamic

Added by @keynmol in #2196

Print platform version

Platform version is now always logged during compilation.

scala-cli compile .
# Compiling project (Scala 3.3.1, JVM (17))
# Compiled project (Scala 3.3.1, JVM (17))
scala-cli compile . --js
# Compiling project (Scala 3.3.1, Scala.js 1.13.2)
# Compiled project (Scala 3.3.1, Scala.js 1.13.2)
scala-cli compile . --native
# Compiling project (Scala 3.3.1, Scala Native 0.4.16)
# Compiled project (Scala 3.3.1, Scala Native 0.4.16)

Added by @Gedochao in #2465

Other changes

Enhancements

Fixes

Documentation changes

Build and internal changes

  • Add test for actionable diagnostics from compiler by @MaciejG604 in #2327
  • Pin the versions of Github CI runners by @MaciejG604 in #2370
  • Remove bloop timeouts in tests by @MaciejG604 in #2407
  • Add post-update hook for reference doc generation by @MaciejG604 in #2406
  • Add tests which check availability of scalafmt native launcher for de… by @lwronski in #2418
  • Default to a Scala version for REPL if there are no Scala artifacts. by @trilleplay in #2431
  • Remove unused snippet checker by @lwronski in #2423
  • Allow to override internal & user default Scala versions for mill builds by @Gedochao in #2461
  • NIT: Refactor: Rely on global --power option where able in cli commands by @Gedochao in #2480

Updates and maintenance

Read more

v1.0.4

09 Aug 20:13
6fd1e43
Compare
Choose a tag to compare

Hotfix for buildTarget/jvmRunEnvironment in BSP

We've addressed a bug that surfaced when opening your ScalaCLI projects in Metals or IntelliJ. If you encountered the following log:

2023.08.09 15:48:34 INFO  BSP server: Caused by: java.lang.IllegalArgumentException: Type ch.epfl.scala.bsp4j.JvmMainClass is instantiated reflectively but was never registered. Register the type by adding "unsafeAllocated" for the type in reflect-config.json.
2023.08.09 15:48:34 INFO  BSP server: 	at com.oracle.svm.core.graal.snippets.SubstrateAllocationSnippets.instanceHubErrorStub(SubstrateAllocationSnippets.java:309)
2023.08.09 15:48:34 INFO  BSP server: 	at jdk.unsupported@17.0.6/sun.misc.Unsafe.allocateInstance(Unsafe.java:864)
2023.08.09 15:48:34 INFO  BSP server: 	... 36 more

those logs should no longer appear. Thanks to @lwronski for providing the fix in #2342.

What's Changed

  • Update scala-cli.sh launcher for 1.0.3 by @github-actions in #2338
  • Add missing note to release notes about rename parameter by @lwronski in #2340
  • Back port of documentation changes to main by @github-actions in #2341
  • Fix - support jvmRunEnvironment request for native launcher of scala-cli by @lwronski in #2342
  • 1.0.4 release notes by @lwronski in #2343

Full Changelog: v1.0.3...v1.0.4

v1.0.3

08 Aug 17:47
83bc7bc
Compare
Choose a tag to compare

What's new

Access project configuration with the new BuildInfo

BuildInfo access your project's build configuration within your Scala code. This feature automatically gathers and generates build information about your project, making project details instantly accessible at runtime.

To generate BuildInfo, either use the --build-info command line option or include the //> using buildInfo directive in your code.

Upon activation, a BuildInfo object becomes accessible on your project's classpath. To use it, simply add the following import into your code:

import scala.cli.build.BuildInfo

This BuildInfo object encapsulates information such as the Scala version used, target platform, main class, scalac options, dependencies, and much more for both Main and Test scopes. The generation ensures up-to-date configuration data from both the console options and using directives in your project's sources.

Added by @MaciejG604 in #2249.

CompileOnly Dependencies

Now, users can declare dependencies that are exclusively included at the compile time. These dependencies are added to the classpath during compilation, but won't be included when the application is run, keeping your runtime environment lightweight.

To declare such a dependency:

  1. Via the using directive:
//> using compileOnly.dep "com.github.plokhotnyuk.jsoniter-scala::jsoniter-scala-macros:2.23.2"
  1. Via the command line:
scala-cli Hello.scala --compile-dep "com.github.plokhotnyuk.jsoniter-scala::jsoniter-scala-macros:2.23.2"

Added by @alexarchambault and @lwronski in #2299, Thanks!

Set globally Java properties

Scala CLI allows users to globally set Java properties for its launcher using the config command. This will simplify the JVM properties management process, eliminating the need to pass these properties with each scala-cli execution.

To set global Java properties execute the following command:

scala-cli config java.properties Djavax.net.ssl.trustStore=cacerts Dfoo=bar2

When modifying Java properties, remember that you must redefine all of them. It's not possible to update just a single property. Essentially, each time you use the config command for Java properties, you replace the entire list of properties.

Whenever overwriting existing Java properties Scala CLI will let you know what was the previous value and in interactive mode ensure that you are ok with replacing them.

Added by @lwronski in #2317, Thanks!

Rename parameter for publish command

We've updated the --version parameter for the publish command. Now, when specifying the project version, use --project-version instead.

scala-cli publish --project-version 1.0.3 ...

Other changes

  • Add custom exception and throw it when node not found in the path by @lwronski in #2323
  • Skip reading ide-options-v2.json if doesn't exist to avoid throwing a… by @lwronski in #2333
  • Skip setting release flag when user pass directly -release or -java-o… by @lwronski in #2321
  • Prevent downloading Java 17 when running a REPL without sources by @lwronski in #2305
  • Extract JAVA_HOME from /usr/libexec/java_home for Mac by @lwronski in #2304
  • Bump case-app, add names limit to HelpFormat, move some name aliases, add test by @MaciejG604 in #2280
  • Build info with compute version @MaciejG604 in #2310

Fixes

  • Fix - install ps, which is necessary for starting Bloop by @lwronski in #2332
  • Load virtual data as byte arrays without encoding using UTF-8 by @lwronski in #2313
  • Accept directive packageType native when using native platform by @lwronski in #2311
  • Ignore url query params @MaciejG604 in #2334

Documentation changes

Build and internal changes

Updates and maintenance

Full Changelog: v1.0.2...v1.0.3

v1.0.2

11 Jul 13:29
8bb97d9
Compare
Choose a tag to compare

What's new

This release brings enhancements to Scala CLI:

  • WinGet installation for Windows users
  • better navigation with improved build target names
  • introducing new command for Giter8 project generation
  • easier JVM properties management with .scalaopts file support.

The release also includes numerous bug fixes, updates, and new contributors.

Installation via WinGet on Windows

Scala CLI can now be installed via WinGet on Windows, with
a command such as

winget install virtuslab.scalacli

Added by @mimoguz in #2239, Thanks!

Enhanced build target names

Now, the build target name will be derived from the workspace directory that contains it, making it easier for users to
navigate between different projects within a multi-root workspace. Instead of a build target named as project_XYZ-XYZ,
you will now see the name like workspace_XYZ-XYZ, where workspace refers to the name of the workspace directory.

.
├── scripts
│   ├── .scala-build
│   │   └── scripts_59f2159dd5
│   └── one.sc
├── skan
│   ├── .scala-build
│   │   └── skan_88b44a2858
│   └── main.scala
└── skan.code-workspace

Added by @MaciejG604 in #2201

Introducing 'new' command for Giter8 project generation

Giter8 is a project templating tool for Scala, and its integration within Scala CLI offers efficient way to set up new
projects. By using the new command, users can generate new projects based on predefined or custom templates.

For example:

scala-cli --power new VirtusLab/scala-cli.g8

Added by @zetashift in #2202, Thanks!

Loading Java Properties from .scalaopts into ScalaCLI launcher

ScalaCLI allows to load Java properties into scala-cli launcher directly from a .scalaopts file located in your
current working directory. This will simplify the JVM properties management process, eliminating the need to pass these
properties with each scala-cli execution.

For instance, if -Djavax.net.ssl.trustStore=cacerts and -Dfoo2=bar2 are defined within your .scalaopts file, these
values will be loaded into scala-cli launcher:

$ cat .scalaopts
-Djavax.net.ssl.trustStore=cacerts
-Dfoo2=bar2
$ scala-cli run ...

Added by @lwronski in #2267

Please be aware that ScalaCLI will only process Java properties that it recognizes from the .scalaopts file. Other JVM
options, such as -Xms1024m, will be ignored as they can't be used within native image, and users will be alerted with
a warning message when such non-compliant options are passed.

Other changes

Fixes

Documentation changes

Build and internal changes

Updates and maintenance

New Contributors

Read more

v1.0.1

06 Jun 15:51
83c41ab
Compare
Choose a tag to compare

What's new

This release only contains bug fixes and minor internal improvements.

Fixes

  • Fix - add test to output from name of script example by @lwronski in #2153
  • Fix publishing with implicit publish.version coming from a git tag by @Gedochao in #2154
  • Fix conflicts when watch and interactive try to read StdIn by @MaciejG604 in #2168
  • Bsp wrapper fixes by @MaciejG604 in #2171
  • Add the .exe suffix to output provided by user for graalvm-native-image by @lwronski in #2182

Build and internal changes

  • refactor: Remove JavaInterface, which causes compilation issues with Bloop by @tgodzik in #2174
  • Enforce to use jvm 17 on linux aarch64 by @lwronski in #2180

Updates and maintenance

Full Changelog: v1.0.0...v1.0.1

v1.0.0

24 May 13:38
Compare
Choose a tag to compare

The official scala runner release

Scala CLI has reached the highly anticipated 1.0.0 milestone!
Having addressed all the SIP-46 requirements,
this version is going to become the official scala runner, replacing the old scala command.

For a deeper understanding of Scala CLI as the new scala runner and to explore its benefits and features,
we encourage you to check out our blogpost.

Also be sure to get familiar with all the differences introduced by this change in our migration guide.

What's Changed

New default Scala version - 3.3.0

Scala 3.3.0 is now the default version for Scala CLI projects.
It's the first LTS (Long Term Support) release of Scala 3 to be used by Scala CLI.
Right on time for 1.0.0!

Added by @lwronski #2140

Toolkit-test

By incorporating the Scala Toolkit into your project, you gain the advantage of two additional
dependencies seamlessly integrated into your classpath:

  • org.scala-lang:toolkit:<version> is added to the main scope, allowing its utilization throughout your project.
  • org.scala-lang:toolkit-test:<version> is included in the test scope, making it available exclusively for testing purposes.

Scala CLI now supports the following features for the toolkit:

  • including e.g. //> using toolkit latest in any main scope file will automatically add the toolkit dependency to the main scope and the toolkit-test dependency to the test scope
  • if you place e.g. //> using toolkit latest within a test scope file, both toolkit and toolkit-test will be limited to the test scope only
  • inserting e.g. //> using test.toolkit latest anywhere in the project will add both toolkit and toolkit-test to the test scope only

This convention is encouraged for other toolkit-like libraries as well.

Added by @Gedochao #2127 and #2137

Forcing an object wrapper for scripts

Scala CLI now supports the //> using objectWrapper directive, along with the corresponding --object-wrapper option,
which allows to force wrapping script code in an object body instead of a class.

Using object wrappers should be avoided for scripts relying on multi-threading (as it may cause deadlocks), but may prove to be the only option in some cases.

Added by @MaciejG604 #2136

Other changes

  • Add alias for snapshots repository in Maven by @lwronski #2125
  • Bump typelevel-toolkit to 0.0.11, configure toolkit-test by @armanbilge #2135
  • Fix updating toolkit dependencies by @Gedochao #2138
  • Improve directive parsing errors & special-case toolkit directive version parsing by @Gedochao #2133
  • Fix determining position for value in directive without quotes by @lwronski #2141

Fixes

Documentation changes

Build and internal changes

Updates and maintenance

  • Update scala-cli.sh launcher for 1.0.0-RC2 by @github-actions #2105
  • Update org.eclipse.jgit to 6.5.0.202303070854-r by @scala-steward #2090

New Contributors

Full Changelog: v1.0.0-RC2...v1.0.0