A box around a Linker to support clearing.
ECMAScript features to use when linking to JavaScript.
ECMAScript features to use when linking to JavaScript.
The options in ESFeatures
specify what features of modern versions of
JavaScript are used by the Scala.js linker.
useX
*force* the linker to use the
corresponding features, guaranteeing that the specific semantics that
they provide will be used.allowX
*allow* the linker to use the
corresponding features if it supports them. Support for such options can
be dropped in any subsequent version of the linker, including patch
versions.avoidX
*hint* at the linker to avoid
the corresponding features *when it does not affect observable
semantics*. They are related to optimizations (for performance or code
size). The linker is free to ignore those options.
Centralized Scala.js IR cache.
Centralized Scala.js IR cache.
Caches all Scala.js IR used in a given JVM. It supports creating of multiple sub-caches (IRFileCache.Cache) that track individual file sets. The global cache is fully thread-safe. However, the sub-caches are not.
Configuration of an IRFileCache.
A Scala.js linker, with its most abstract API.
A Scala.js linker, with its most abstract API.
A linker can take a sequence of virtual .sjsir files and a sequence of module initializers, link them together, and write the resulting JS file(s) to a directory.
Further, the linker returns a Report about the run.
Thrown by the linker when linking cannot be performed.
A module initializer for a Scala.js application.
A module initializer for a Scala.js application.
When linking a Scala.js application, a sequence of ModuleInitializer
s can
be given. Those module initializers will be executed at the startup of the
application. More specifically, the top-level code of the relevant
ECMAScript 2015 module emitted will invoke the specified module
initializers in the specified order, after having initialized everything
else (notably static initializers).
Instances of ModuleInitializer
can be created with methods of
the ModuleInitializer companion object.
The module in which a ModuleInitializer
is going to be placed can be
adjusted using withModuleID.
Kind of module structure emitted for the Scala.js output.
How to split the output into modules.
Directory where the linker will write its output files.
Output patterns configure how the linker names/refers to modules it created.
Output patterns configure how the linker names/refers to modules it created.
Internally, the linker refers to every module using an abstract module ID.
For public modules (i.e. modules that can be imported), the module ID is provided by the user.
For internal modules (i.e. modules used to share code), the module ID is generated by the linker.
Currently, all with*
methods expect a Formatter
pattern taking the module ID as sole string (%s
) argument.
Information about a linker run.
Configuration of a standard linker.
Output specification for a linker run.
Output specification for a linker run.
(Since version 1.3.0) Part of old Linker interface
Factory for ModuleInitializers.
(Since version 1.3.0) Part of old Linker interface
Backwards compatibility implementation for pre 1.3.0 link method.
Backwards compatibility implementation for pre 1.3.0 link method.
The major interface change in 1.3.0 is that the linker (and not the caller) determines the set of files to be written. As a consequence, the post 1.3.0 API does not offer as much control over cross-file references (i.e. source map links): it is based on patterns rather than simply asking the caller to verbatim provide the URI to reference in each file.
To provide a backwards compatible interface, we do the following post-run processing:
(Since version 1.3.0) Part of legacy API.
A box around a Linker to support clearing.
Calling
clear()
completely resets the state of thisClearableLinker
, so that it can be used again without being affected by previous calls tolink
, even of those would have corrupted the internal state.In addition to the contract of Linker, if {{Linker.link}} throws an exception, the
ClearableLinker
is automaticallyclear()
'ed.Implementations are allowed to automatically
clear()
in other cases, but never while a linking is in progress.Unless otherwise specified, instances of this trait are not thread-safe.