Swift framework to interact with JavaScript through WebAssembly.
MIT License
JSClosure
leak by @kateinoigakukun in https://github.com/swiftwasm/JavaScriptKit/pull/240
sharedMemory
option to allow threads with shared memory by @kateinoigakukun in https://github.com/swiftwasm/JavaScriptKit/pull/247
Full Changelog: https://github.com/swiftwasm/JavaScriptKit/compare/0.19.2...0.19.3
Published by kateinoigakukun 7 months ago
Full Changelog: https://github.com/swiftwasm/JavaScriptKit/compare/0.19.1...0.19.2
Published by kateinoigakukun 9 months ago
Full Changelog: https://github.com/swiftwasm/JavaScriptKit/compare/0.19.0...0.19.1
Published by kateinoigakukun 9 months ago
Full Changelog: https://github.com/swiftwasm/JavaScriptKit/compare/0.18.0...0.19.0
Published by kateinoigakukun over 1 year ago
UInt(bitPattern:)
for object id to guarantee uniqueness by @kateinoigakukun in https://github.com/swiftwasm/JavaScriptKit/pull/219
withUnsafeBytesAsync
function to JSTypedArray
by @fjtrujy in https://github.com/swiftwasm/JavaScriptKit/pull/222
Full Changelog: https://github.com/swiftwasm/JavaScriptKit/compare/0.17.0...0.18.0
Published by kateinoigakukun about 2 years ago
JavaScriptEventLoop.queueMicrotask
and .setTimeout
by @kateinoigakukun in https://github.com/swiftwasm/JavaScriptKit/pull/214
Full Changelog: https://github.com/swiftwasm/JavaScriptKit/compare/0.16.0...0.17.0
Published by kateinoigakukun about 2 years ago
This release contains significant performance improvements, API enhancements for JSPromise
/ JSBigInt
/ JSClosure
, and documentation improvements.
Merged pull requests:
Published by MaxDesiatov over 2 years ago
This is a major release that adds new features and fixes issues. Specifically:
BigInt
and BigInt
-based JSTypedArray
types are now supported. Now, when passing Int64
values from Swift, they will be mapped to BigInt
values on the JavaScript side.constructor
property on JSBridgedClass
is now an Optional
, which allows bridging JavaScript classes that aren't available in every browser or environment.carton
that could lead to a version mismatch between JavaScriptKit dependency in Package.swift
or Package.resolved
and carton’s bundled JavaScriptKit runtime version.JSSymbol
type has been added, enabling support for JavaScript Symbol
values, including accessing Symbol
-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:
JSBridgedClass
(#190) via @MaxDesiatovREADME.md
(#189) via @MaxDesiatovBigInt
support FIXME
from JSTypedArray
(#187) via @MaxDesiatovJSFunction.swift
(#182) via @MaxDesiatovPublished by MaxDesiatov over 2 years ago
This is a breaking release that enables full support for SwiftWasm 5.6 and lays groundwork for future updates to DOMKit.
Specifically:
ConvertibleToJSValue
conformance on Array
and Dictionary
has been swapped from the == ConvertibleToJSValue
case to the : ConvertibleToJSValue
case.
[String]
is now ConvertibleToJSValue
, but [ConvertibleToJSValue]
no longer conforms;jsValue()
method still works in both cases;.map { $0.jsValue() }
(or mapValues
) to get an array/dictionary of JSValue
which you can then use as ConvertibleToJSValue
.jsValue
to the end of all of the values in the array/dictionary literal.Merged pull requests:
Published by MaxDesiatov over 2 years ago
This release improves handling of JavaScript exceptions and compatibility with Xcode.
Thanks to @kateinoigakukun, @pedrovgs, and @valeriyvan for contributions!
Closed issues:
Merged pull requests:
@available
for Xcode development (#171) via @kateinoigakukunPublished by yonihemi over 2 years ago
This release introduces a major refactor of the JavaScript runtime by [@j-f1] and several performance enhancements.
Merged pull requests:
Hashable
conformance to JSObject
(#162) via @yonihemiArrayBuffer
(#154) via @yonihemiArrayBuffer
errors (#153) via @yonihemiinstallGlobalExecutor()
from running more than once (#152) via @yonihemiTypedArray.set
to copy a bunch of bytes (#146) via @kateinoigakukunPublished by MaxDesiatov almost 3 years ago
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
.unsafeFlags(["-Xfrontend", "-disable-availability-checking"])
in Package.swift
manifest.Merged pull requests:
Package.swift
(#144) via @MaxDesiatov
Published by MaxDesiatov almost 3 years ago
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:
FinalizationRegistry
to auto-deinit JSClosure
(#131)make test
crashes due to JSClosure
memory issues (#129)JSClosure
(#106)Merged pull requests:
JSTypedArray
initializer (#142) via @PatrickPijnappel
Example
project (#140) via @MaxDesiatov
JSClosure
to leverage FinalizationRegistry
(#128) via @j-f1
Published by MaxDesiatov over 3 years ago
This is a minor patch release that includes updates to our dependencies and minor documentation tweaks.
Closed issues:
JSPromise
(#121)JSBridgedClass
for WebSocket.send
(#120)Merged pull requests:
JSDate
documentation (#122) via @revolter
Published by MaxDesiatov almost 4 years ago
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 of JSFunction
. These classes are not related enough to keep them in the same class hierarchy. As a result, you can no longer call JSClosure
objects directly from Swift. Call wrapped closures directly instead.JSOneshotClosure
for closures that are going to be called only once. You don't need to manage references to these closures manually, as opposed to JSClosure
. 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.JSPromise
, now both success and failure values are always assumed to be of JSValue
type. This also significantly simplifies type checking and allows callers to fully control type casting if needed.Closed issues:
Merged pull requests:
JSPromise
API (#115) via @kateinoigakukun
FUNDING.yml
(#117) via @MaxDesiatov
JSClosure
(#113) via @kateinoigakukun
package.json
to lockfileVersion 2 (#114) via @kateinoigakukun
ini
from 1.3.5 to 1.3.8 in /Example
(#111) via @dependabot[bot]
JSTypedArray.swift
(#110) via @MaxDesiatov
Published by MaxDesiatov almost 4 years ago
This release introduces support for catching JSError
instances in Swift from throwing JavaScript functions. This is possible thanks to the new JSThrowingFunction
and JSThrowingObject
classes. The former can only be called with try
, while the latter will expose all of its member functions as throwing. Use the new throws
property on JSFunction
to convert it to JSThrowingFunction
, and the new throwing
property on JSObject
to convert it to JSThrowingObject
.
Closed issues:
Merged pull requests:
compatibility.yml
(#105) via @MaxDesiatov
carton
Docker image and refine wording in README.md
(#101) via @MaxDesiatov
Published by MaxDesiatov about 4 years ago
This release introduces a few enhancements and deprecations. Namely, JSValueConstructible
and JSValueConvertible
were renamed to ConstructibleFromJSValue
and ConvertibleToJSValue
respectively. The old names are deprecated, and you should move away from using the old names in your code. Additionally, JavaScriptKit now requires the most recent 5.3 and development toolchains, but thanks to this it no longer uses unsafe flags, which prevented building other libraries depending on JavaScriptKit on other platforms.
The main user-visible enhancement is that now force casts are no longer required in client code. That is, we now allow this
let document = JSObject.global.document
let foundDivs = document.getElementsByTagName("div")
in addition to the previously available explicit style with force unwrapping:
let document = JSObject.global.document.object!
let foundDivs = document.getElementsByTagName!("div").object!
Note that the code in the first example is still dynamically typed. The Swift compiler won't warn you if you misspell names of properties or cast them to a wrong type. This feature is purely additive, and is added for convenience. You can still use force unwraps in your code interfacing with JavaScriptKit. If you're interested in a statically-typed DOM API, we recommend having a look at the DOMKit library, which is currently in development.
Lastly, JSError
now conforms to the JSBridgedClass
protocol, which makes it easier to integrate with idiomatic Swift code.
Closed issues:
JSValueConstructible
and JSValueConvertible
(#87)Merged pull requests:
README.md
(#100) via @MaxDesiatov
README.md
(#96) via @MaxDesiatov
JSError
conform to JSBridgedClass
(#86) via @MaxDesiatov
Published by MaxDesiatov about 4 years ago
This is a bugfix release that resolves an issue with the JavaScript runtime being unavailable when installed via NPM.
Closed issues:
Merged pull requests:
package.json
(#81) via @MaxDesiatov
README.md
(#78) via @MaxDesiatov
Published by MaxDesiatov about 4 years ago
This release adds multiple new types bridged from JavaScript, namely JSError
, JSDate
, JSTimer
(which corresponds to setTimeout
/setInterval
calls and manages closure lifetime for you), JSString
and JSPromise
. We now also have documentation published automatically for the main branch.
Closed issues:
TypedArray
improvement? (#52)Merged pull requests:
JSPromise
implementation (#62) via @MaxDesiatov
JSString
to reduce bridging overhead (#63) via @kateinoigakukun
JSBridgedType
and JSBridgedClass
(#26) via @j-f1
JSValue
conform to ExpressibleByNilLiteral
(#59) via @j-f1
JavaScriptTypedArrayKind
(#58) via @j-f1
ref
to jsObject
on JSDate for consistency with JSError (#50) via @MaxDesiatov
swift-doc
(#49) via @MaxDesiatov
JSTimer
implementation with tests (#46) via @MaxDesiatov
JSError.stack
, add Error
conformance (#48) via @MaxDesiatov
JSDate
implementation with tests (#45) via @MaxDesiatov
JSError
with tests, add JSObject.description (#47) via @MaxDesiatov