Releases: swiftwasm/JavaScriptKit
0.17.0
What's Changed
- Bump @actions/core from 1.2.6 to 1.9.1 in /ci/perf-tester by @dependabot in #209
- Remove baseline tests (e.g. “Call JavaScript function directly”) from comparison by @j-f1 in #211
- Add 5.7 toolchain matrix by @kateinoigakukun in #210
- Add JavaScriptEventLoopTestSupport module to install executor by @kateinoigakukun in #213
- Expose
JavaScriptEventLoop.queueMicrotask
and.setTimeout
by @kateinoigakukun in #214
Full Changelog: 0.16.0...0.17.0
0.16.0
This release contains significant performance improvements, API enhancements for JSPromise
/ JSBigInt
/ JSClosure
, and documentation improvements.
Merged pull requests:
- Runtime Performance Optimization (#207) via @kateinoigakukun
- Add missing doc comments for more types (#208) via @MaxDesiatov
- Add Int64/UInt64 to Bigint slow conversion (#204) via @kateinoigakukun
- Test native builds with Xcode 14.0 (#206) via @MaxDesiatov
- Support DocC generation in Swift Package Index (#205) via @MaxDesiatov
- Refine benchmark suite (#203) via @kateinoigakukun
- Add diagnostics for those who build with WASI command line ABI (#202) via @kateinoigakukun
- Bump terser from 5.10.0 to 5.14.2 in /Example (#201) via @dependabot[bot]
- Test with uwasi implementation (#198) via @kateinoigakukun
- Add async JSPromise.result property (#200) via @kateinoigakukun
- Asynchronous calls in JSClosure (#157) via @j-f1
- JSPromise(resolver:) usage (#156) via @j-f1
0.15.0
This is a major release that adds new features and fixes issues. Specifically:
BigInt
andBigInt
-basedJSTypedArray
types are now supported. Now, when passingInt64
values from Swift, they will be mapped toBigInt
values on the JavaScript side.- The
constructor
property onJSBridgedClass
is now anOptional
, which allows bridging JavaScript classes that aren't available in every browser or environment. - JavaScriptKit runtime files are now supplied as SwiftPM resources. This allows us to resolve a long-standing issue in
carton
that could lead to a version mismatch between JavaScriptKit dependency inPackage.swift
orPackage.resolved
and carton’s bundled JavaScriptKit runtime version. - The
JSSymbol
type has been added, enabling support for JavaScriptSymbol
values, including accessingSymbol
-keyed properties on objects.
Source breaking changes
UInt64.jsValue
and Int64.jsValue
, which are a part of JavaScriptKit
module, have been moved into JavaScriptBigIntSupport
module since their implementation changed to require JS-BigInt-integration to avoid implicit casts from 64-bit integer to JS number type.
If you want to keep the behavior so far, please cast the 64-bit integer values to Double
.
Merged pull requests:
- Improve JSKit diagnostics for use-after-free of JSClosure (#195) via @kateinoigakukun
- Gracefully handle unavailable
JSBridgedClass
(#190) via @MaxDesiatov - Supply JSKit runtime in SwiftPM resources (#193) via @MaxDesiatov
- Test with Node.js's WASI implementation (#192) via @kateinoigakukun
- Add support for BigInts and BigInt-based TypedArrays (#184) via @j-f1
- Update toolchain references to 5.6.0 in
README.md
(#189) via @MaxDesiatov - Bump async from 2.6.3 to 2.6.4 in /Example (#188) via @dependabot
- Remove outdated
BigInt
supportFIXME
fromJSTypedArray
(#187) via @MaxDesiatov - Cleanup & improvements to perf-tester (#186) via @j-f1
- Re-add support for Symbol objects via JSSymbol (#183) via @j-f1
- Fix JSValueDecoder (#185) via @j-f1
- Fix deprecation warning in
JSFunction.swift
(#182) via @MaxDesiatov
0.14.0
This is a breaking release that enables full support for SwiftWasm 5.6 and lays groundwork for future updates to DOMKit.
Specifically:
- The
ConvertibleToJSValue
conformance onArray
andDictionary
has been swapped from the== ConvertibleToJSValue
case to the: ConvertibleToJSValue
case.- This means that e.g.
[String]
is nowConvertibleToJSValue
, but[ConvertibleToJSValue]
no longer conforms; - the
jsValue()
method still works in both cases; - to adapt existing code, use one of these approaches:
- use generics where possible (for single-type arrays)
- call
.map { $0.jsValue() }
(ormapValues
) to get an array/dictionary ofJSValue
which you can then use asConvertibleToJSValue
- add
.jsValue
to the end of all of the values in the array/dictionary literal.
- This means that e.g.
Merged pull requests:
- Reenable integration tests (#180) via @kateinoigakukun
- Updates for DOMKit (#174) via @j-f1
- Add 5.6 release and macOS 12 with Xcode 13.3 to CI matrix (#176) via @MaxDesiatov
0.13.0
This release improves handling of JavaScript exceptions and compatibility with Xcode.
Thanks to @kateinoigakukun, @pedrovgs, and @valeriyvan for contributions!
Closed issues:
Merged pull requests:
- Improve error messages when JS code throws exceptions (#173) via @pedrovgs
- Update npm dependencies (#175) via @MaxDesiatov
- Bump minimist from 1.2.5 to 1.2.6 in /Example (#172) via @dependabot
- Use availability guarded APIs under
@available
for Xcode development (#171) via @kateinoigakukun - Fix warning in snippet (#166) via @valeriyvan
- Bump follow-redirects from 1.14.5 to 1.14.8 in /Example (#165) via @dependabot
0.12.0
This release introduces a major refactor of the JavaScript runtime by [@j-f1] and several performance enhancements.
Merged pull requests:
- Add
Hashable
conformance toJSObject
(#162) via @yonihemi - Add test for detached
ArrayBuffer
(#154) via @yonihemi - Fix detached
ArrayBuffer
errors (#153) via @yonihemi - Split runtime into multiple files (#150) via @j-f1
- Add a way for Swift code to access raw contents of a Typed Array (#151) via @yonihemi
- Prevent
installGlobalExecutor()
from running more than once (#152) via @yonihemi - Return from runtime functions instead of taking a pointer where possible (#147) via @j-f1
- Use
TypedArray.set
to copy a bunch of bytes (#146) via @kateinoigakukun
0.11.1
This is a bugfix release that removes a requirement for macOS Monterey in Package.swift
for this package. README.md
was updated to explicitly specify that if you're building an app or a library that depends on JavaScriptKit for macOS (i.e. cross-platform code that supports both WebAssembly and macOS), you need either
- macOS Monterey that has the new Swift concurrency runtime available, or
- any version of macOS that supports Swift concurrency back-deployment with Xcode 13.2 or later, or
- add
.unsafeFlags(["-Xfrontend", "-disable-availability-checking"])
inPackage.swift
manifest.
Merged pull requests:
- Remove macOS Monterey requirement from
Package.swift
(#144) via @MaxDesiatov
0.11.0
This release adds support for async
/await
and SwiftWasm 5.5. Use the new value
async property on a JSPromise
instance to await
for its result. You'll have to add a dependency on the new JavaScriptEventLoop
target in your Package.swift
, import JavaScriptEventLoop
, and call JavaScriptEventLoop.installGlobalExecutor()
in your code before you start using await
and Task
APIs.
Additionally, manual memory management API of JSClosure
has been removed to improve usability. This significantly bumps minimum browser version requirements for users of apps depending on JavaScriptKit. Previous manual memory management mode is still available though with a special compiler flags, see README.md
for more details.
This new release of JavaScriptKit may work with SwiftWasm 5.4 and 5.3, but is no longer tested with those versions due to compatibility issues introduced on macOS by latest versions of Xcode.
Many thanks to @j-f1, @kateinoigakukun, and @PatrickPijnappel for their contributions to this release!
Closed issues:
- Enchancement: Add a link to the docs (#136)
- Use
FinalizationRegistry
to auto-deinitJSClosure
(#131) make test
crashes due toJSClosure
memory issues (#129)- Avoid manual memory management with
JSClosure
(#106)
Merged pull requests:
- Fix recursion in
JSTypedArray
initializer (#142) via @PatrickPijnappel - Experimental global executor cooperating with JS event loop (#141) via @kateinoigakukun
- Update NPM dependencies of
Example
project (#140) via @MaxDesiatov - Refactor
JSClosure
to leverageFinalizationRegistry
(#128) via @j-f1 - Test with the latest 5.5 snapshot (#138) via @MaxDesiatov
- Test with multiple toolchain versions (#135) via @kateinoigakukun
- Gardening tests (#133) via @kateinoigakukun
0.10.1
This is a minor patch release that includes updates to our dependencies and minor documentation tweaks.
Closed issues:
- Do you accept contributions for wrappers over JavaScript objects? (#124)
- Can't read from a file using
JSPromise
(#121) - TypeError when trying to implement a
JSBridgedClass
forWebSocket.send
(#120)
Merged pull requests:
- Update JS dependencies in package-lock.json (#126) via @MaxDesiatov
- Fix typo in method documentation (#125) via @revolter
- Update exported func name to match exported name (#123) via @kateinoigakukun
- Fix incorrect link in
JSDate
documentation (#122) via @revolter
0.10.0
This release contains multiple breaking changes in preparation for enabling async
/await
, when this feature is available in a stable SwiftWasm release. Namely:
JSClosure.init(_ body: @escaping ([JSValue]) -> ())
overload is deprecated to simplify type checking. Its presence requires explicit type signatures at the place of use. It will be removed in a future version of JavaScriptKit.JSClosure
is no longer a subclass ofJSFunction
. These classes are not related enough to keep them in the same class hierarchy. As a result, you can no longer callJSClosure
objects directly from Swift. Call wrapped closures directly instead.- Introduced
JSOneshotClosure
for closures that are going to be called only once. You don't need to manage references to these closures manually, as opposed toJSClosure
. However, they can only be called a single time from the JS side. Subsequent invocation attempts will raise a fatal error on the Swift side. - Removed generic parameters on
JSPromise
, now both success and failure values are always assumed to be ofJSValue
type. This also significantly simplifies type checking and allows callers to fully control type casting if needed.
Closed issues:
- DOMKit? (#21)
Merged pull requests:
- Simplify
JSPromise
API (#115) via @kateinoigakukun - Create
FUNDING.yml
(#117) via @MaxDesiatov - Major API change on
JSClosure
(#113) via @kateinoigakukun - Update
package.json
to lockfileVersion 2 (#114) via @kateinoigakukun - Bump
ini
from 1.3.5 to 1.3.8 in/Example
(#111) via @dependabot[bot] - Update doc comment in
JSTypedArray.swift
(#110) via @MaxDesiatov