What's new in SwiftWasm #2
Welcome to the second SwiftWasm update! To make the updates flow steady, we're trying to publish them fortnightly now. Let us know what you think of this new cadence. And here's a gentle reminder that this blog is fully open-source, so if you spot a typo, an error, a broken link, or have any other feedback, please feel free to file it in our
blog.swiftwasm.org GitHub repository.
SwiftWasm team updates
We would like to welcome @yonihemi to the SwiftWasm team who joined us in the beginning of October. After the previous contributions he made to
carton it made perfect sense to expand our team. As always, we invite everyone to contribute to any of our repositories, and it doesn't require much prior experience with SwiftWasm if any at all. Bug fixes, feature additions, improved documentation and related changes are very much appreciated and allow our ecosystem to grow even more!
Package.swift. The use of unsafe flags was a big problem for us, as it breaks dependency resolution due to strict checks that SwiftPM applies. If any package in your dependency tree contains unsafe flags, you can no longer depend on its semantic version, or a semantic version of any other package that depends on it.
JSValueConvertible protocols. These protocols are used for conversions between
JSValue references and arbitrary Swift values. In practice it wasn't always clear which of these protocols was responsible for a specific conversion. After some deliberation, these were renamed to
ConvertibleToJSValue respectively in #88.
let document = JSObject.global.document let foundDivs = document.getElementsByTagName("div")
in addition to the currently available explicit style with force unwrapping:
let document = JSObject.global.document.object! let foundDivs = document.getElementsByTagName!("div").object!
i64 Wasm function return type support in Safari. The reason for it is that Safari is the only major browser that doesn't support Wasm
Tokamak didn't see major updates recently, but we've received some important bug reports during the last few weeks. Firstly, there's an edge case with
Picker views that use
\.self as an identifier keypath. Secondly,
Toggle binding is not reset after its value changes outside of the view. Many thanks to @rbartolome for the extensive testing he's given and for reporting these issues!
In the first half of October @yonihemi submitted two important quality-of-life improvements to
- Allow changing dev server's port (#116).
- Automatically open a browser window when dev server starts (#117).
There's also an open "Pretty print diagnostics" PR #112 submitted by @carson-katri. It does some magic with diagnostic messages emitted by the Swift compiler, highlights relevant lines of code and formats all of it nicely. You can check out a preview on this screenshot:
Not much upstreaming work happened in October yet, but there was some progress in adding cross-compilation support to SourceKit-LSP. We are also preparing a 5.3 SwiftWasm snapshot with this patch, which will enable this new
--destination option on SourceKit-LSP. When that works, we want
carton to infer a value for this option and launch it automatically for you when needed. This is all to make auto-complete work correctly for your SwiftWasm apps and libraries in VSCode or any other LSP-supporting editor or IDE.
A lot of the progress wouldn't be possible without payments from our GitHub Sponsors. Their contribution is deeply appreciated and allows us to spend more time on SwiftWasm projects. You can see the list of sponsors and make your contribution on the sponsorship pages of Carson Katri, Yuta Saito and Max Desiatov.
Thanks for reading! 👋