Announcing Scala.js 1.1.0
May 18, 2020.
We are pleased to announce the release of Scala.js 1.1.0!
The highlight of this release is the new support for @js.native
val
s and def
s, which we detail below.
The version of the Scala standard library has been upgraded to Scala 2.12.11 and 2.13.2.
In addition, it contains a number of bug fixes, including all the ones fixed in v0.6.33.
Important note: if you use scalajs-bundler, you will need to upgrade it to v0.18.0 or later.
Read on for more details.
Getting started
If you are new to Scala.js, head over to the tutorial.
If you need help with anything related to Scala.js, you may find our community on Gitter and on Stack Overflow.
Bug reports can be filed on GitHub.
Release notes
If upgrading from Scala.js 0.6.x, make sure to read the release notes of Scala.js 1.0.0 first, as it contains a host of important information, including breaking changes.
This is a minor release:
- It is backward binary compatible with all earlier versions in the 1.x series: libraries compiled with 1.0.x can be used with 1.1.0 without change.
- It is not forward binary compatible with 1.0.x: libraries compiled with 1.1.0 cannot be used with 1.0.x.
- It is not entirely backward source compatible: it is not guaranteed that a codebase will compile as is when upgrading from 1.0.x (in particular in the presence of
-Xfatal-warnings
).
As a reminder, libraries compiled with 0.6.x cannot be used with Scala.js 1.x; they must be republished with 1.x first.
New warnings
These changes already exist in Scala.js 0.6.33, but are new compared to 1.0.1.
In Scala.js 1.1.0, the Scala.js compiler will start reporting warnings when trying to override equals
and hashCode
in a JS type (extending js.Any
).
For example:
will report the following warnings:
Overriding equals
and hashCode
never worked, in the sense that it would not affect ==
and ##
.
The new warnings make it clear.
New features
@js.native
val
s and def
s
Scala.js 1.1.0 adds support for @js.native
val
s and def
s (but not lazy val
s, var
s or setter def
s) in Scala object
s.
For example:
The rhs of such members must be = js.native
, and they must have an @JSGlobal
or @JSImport
annotation to specify where to load it from.
As illustrated by the above example, they are particularly suited to import
top-level functions and variables from JavaScript modules, without requiring to import the whole module namespace (with JSImport.Namespace
).
They can also be used to accurately load resources from pseudo-modules, like Webpack allows for CSS, JSON and image files, among others:
Miscellaneous
fastOptJS/fullOptJS invalidates when linker config changes
Previously, changing the linker config would not automatically trigger re-linking.
A manual clean
(or removing the .js
file) was required.
The sbt plugin now automatically detects changes to the linker config and invalidates the generated file if necessary.
Upgrade to GCC v20200315
The Google Closure Compiler used internally by Scala.js for fullOptJS
has been upgraded to v20200315.
Bug fixes
Among others, the following bugs have been fixed in 1.1.0:
- #4021 The Refiner eliminates needed static fields in non-instantiated classes
- #4001 Scala.js 1.0.0 unnecessary generates imports for parent classes
as well as the following bugs, carried from v0.6.33:
- #4034 Incorrect result for
-x
whenx
is+0.0
- #3998 Self-types in non-native JS traits cause confusing error message
- #3818 Linking error for
Future.never
from Scala 2.13 - #3939 Compile error on a method with
@JSName("finalize")
in a non-native JS class
You can find the full list on GitHub.