Announcing Scala.js 1.7.0
Aug 4, 2021.
We are excited to announce the release of Scala.js 1.7.0!
This release fixes a number of bugs.
In particular, regular expressions, available through
java.util.regex.Pattern or Scala’s
.r method, now behave in the same way as on the JVM.
This change has compatibility implications, which we discuss below.
Moreover, this release fixes all the known bugs that were left. As of this writing, Scala.js 1.7.0 has zero known bugs!
The Scala standard library was upgraded to versions 2.12.14 and 2.13.6.
Read on for more details.
If you are new to Scala.js, head over to the tutorial.
Bug reports can be filed on GitHub.
If upgrading from Scala.js 0.6.x, make sure to read the release notes of Scala.js 1.0.0 first, as they contain 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 through 1.6.x can be used with 1.7.0 without change.
- It is not forward binary compatible with 1.6.x: libraries compiled with 1.7.0 cannot be used with 1.6.x or earlier.
- It is not entirely backward source compatible: it is not guaranteed that a codebase will compile as is when upgrading from 1.6.x (in particular in the presence of
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.
Fixes with compatibility concerns
Regular expressions have been fixed to match the JVM behavior
Until Scala.js 1.6.x, the regular expressions provided by
java.util.regex.Pattern, and used by
scala.util.matching.Regex and the
Scala.js 1.7.0 finally fixes this issue, and now correctly implements the semantics of Java regular expressions, although some features are not supported.
Since the old implementation has been there for 7 years, and documented as such, it is possible that this fix will actually break some code in the wild. During the implementation of this feature, we have analyzed the corpus of all Scala.js-only libraries (without JVM support) and extracted all the regexes that they use. We have verified that none of those use cases are impacted by this change. It is still possible that applications are impacted.
It is also possible for some cross-platform libraries to face issues, as we have not covered those. Unlike Scala.js-only libraries, we consider it unlikely that they will have issues with the change of semantics per se, as they already worked on the JVM, with the new semantics.
The biggest danger would be a cross-library that uses the
MULTILINE flag (aka
Indeed, that feature kind of worked before, but is now rejected at
Pattern.compile()-time with a
PatternSyntaxException by default.
The reason is that to correctly implement the semantics of that flag, we need support for look-behind assertions (
That support was only added in ECMAScript 2018, whereas Scala.js targets ES 2015 by default.
It is possible to change that target with the following setting:
Attention! While this enables support for the
If you maintain a library, this restriction applies to all downstream libraries and applications.
We therefore recommend to try and avoid the need for that flag instead. We give several strategies on how to do so on the Regular expressions documentation page. That page also contains many more details on the new support of regular expressions.
Add a configurable header comment in generated .js files
Sometimes, it is desirable to add a header comment in the generated .js files. This is typically used for license information or any other metadata. While it has always been possible to post-process the generated .js files in the build, doing so came at the cost of destroying the source maps.
Scala.js 1.7.0 introduces a new linker configuration,
jsHeader, to specify a comment to insert at the top of .js files:
\n (the UNIX newline).
If non-empty, it must end with a new line.
Allow delegating JS class constructor calls with default params
Until Scala.js 1.6.x, in a JS class, a secondary constructor calling another constructor with default parameters had to specify actual values for all parameters. For example, the following code was rejected:
That restriction has been lifted in Scala.js 1.7.0, so that the above code is now valid.
New JDK APIs
The following JDK classes have been added
Set up the
versionScheme of library artifacts
This release configures the sbt
versionScheme setting for the library artifacts of Scala.js (with
"semver-spec" for the public ones).
This will reduce spurious eviction warnings in downstream projects.
Upgrade to GCC v20210601
We upgraded to the Google Closure Compiler v20210601.
Among others, the following bugs have been fixed in 1.7.0:
- #4507 1.6.0 regression:
new mutable.WrappedArrayBuilder(classTag[Unit]).result()throws a CCE
- #3953 fastOptJS error in scalaz 7.3 with Scala.js 1.0.0
- #3918 Mixed-in field in class inside lazy val rhs is erroneously immutable in the IR -> IR checking error
- #4511 Nested JS Class in JS Class with Scala companion crashes compiler
- #4465 Default parameters in constructors of nested JS classes cause invalid IR
- #4526 Compiler crashes on nested JS class with default constructor params with private companion
- #4469 Better error message when executing tests with Node missing
- #4336 Failing
close()subsequent runs too early
String.split(x: Array[Char])produces bad regexes
You can find the full list on GitHub.