Resolve issues breaking Swift Wasm builds for sql-kit - #190
Merged
Conversation
… a newer version of swift-nio that supports wasm, and needed to narrow scope from the broad NIO dependency to the true dependency of just NIOCore.
Those compiling for wasm will need to find their own version of nio that compiles to wasm. In the near future, most latest versions of nio will compile to wasm, so this shouldn't be an issue.
scottmarchant
marked this pull request as ready for review
June 25, 2025 02:43
scottmarchant
commented
Jun 25, 2025
scottmarchant
commented
Jun 25, 2025
68 tasks
0xTim
reviewed
Jun 25, 2025
1 task
…atform. Otherwise, leave exports and dependencies unchanged to minimize any disruption to downstream dependencies.
…is a release containing the latest wasm compilation fixes.
scottmarchant
commented
Jul 14, 2025
gwynne
requested changes
Jul 28, 2025
…dependencies. Latest testing indicates this won't be breaking to scope down to just NIOCore.
gwynne
approved these changes
Jul 28, 2025
gwynne
changed the title
Contributor
Author
|
Note, if anyone encounters issues with this change due to reliance on the sql-kit export of NIO, then after consuming this change, you may need to add the following import if previously relying on the implicit import.
|
scottmarchant
added a commit
to PassiveLogic/sql-kit
that referenced
this pull request
Jul 30, 2026
Motivation: Since vapor#190 and swift-nio's WASI support, SQLKit itself already builds for `wasm32-unknown-wasip1` with NIOCore linked. The drivers beneath it do not: NIOPosix needs the POSIX sockets and threads WASI preview 1 lacks, so a driver on that platform has no SwiftNIO at all, and a SQLKit that kept its `EventLoopFuture` surface there would impose requirements no driver could implement. Gating NIOCore out keeps `canImport(NIOCore)` uniformly false across the stack on WASI, so one condition selects the async-only configuration everywhere. Modifications: Gate the NIOCore product on `.when(platforms: nonWASIPlatforms)`. Target dependency conditions are evaluated per platform, so on WASI the product is simply not linked and the `canImport(NIOCore)` gates select the `async` API. `.when(platforms:)` can only include, never exclude, so excluding one platform means enumerating the others; the list is the set SPM 6.1 knows about, noted as such so it is not extended without also raising the manifest's tools version. The test target's NIOCore and NIOEmbedded dependencies are gated the same way, as are the suite's imports of them. The suite exercises the `EventLoopFuture` API and is not run on WASI, and `swift build` evaluates `--explicit-target-dependency-import-check` for every target in the graph, including the test target it does not build. Result: On every other platform the resolved dependency set is byte-identical to before. On WASI the build graph contains no SwiftNIO module: not NIOPosix, not NIOCore, not NIOConcurrencyHelpers.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
These changes are now available in 3.33.1
Summary
This PR adds support for compiling sql-kit to wasm using the Swift SDK for WebAssembly.
This PR is part of a larger effort by a company called PassiveLogic to enable broad support for Swift WebAssembly.
Details
NIOCoreinstead of the broaderNIO.Notes
Testing done
swift buildcompletes without errorsswift build --swift-sdk wasm32-unknown-wasicompletes without errors, when using a compatible nio version.swift build --swift-sdk wasm32-unknown-wasip1-threadscompletes without errors, when using a compatible nio version.swift package --swift-sdk wasm32-unknown-wasip1-threads js --use-cdnImpact Risk
There is a chance the changes to the manifest and exports could be a breaking change somewhere, if downstream dependencies relied on those pieces for their one and only intrinsic inclusion of the entire NIO dependency beyond NIOCore.
There are solutions to narrow the scope to just wasm compilation for those changes, if that is an issue. But I chose to leave them this way since it is a little cleaner solution.