WASI support: build SQLKit without SwiftNIO - #3
Draft
scottmarchant wants to merge 2 commits into
Draft
Conversation
scottmarchant
force-pushed
the
feat/wasi-nio-free
branch
from
July 29, 2026 00:20
224a265 to
84ba06c
Compare
Motivation: SwiftNIO cannot be built for `wasm32-unknown-wasip1`: NIOPosix is built on POSIX sockets and threads, neither of which WASI preview 1 provides. SQLKit needs very little of SwiftNIO — only `EventLoop` and `EventLoopFuture`, and only for the legacy half of an API whose `async` half is already the recommended one — so it can build without it, given somewhere to put the differences. The goal is one implementation with a few conditional declarations, not a second copy of the package that has to be kept in step by hand. Modifications: Gate the legacy `EventLoopFuture` surface with `#if canImport(NIOCore)`. Keying on `canImport` rather than on a platform keeps the sources in step with whatever the manifest resolves for the target being built, and makes the gate unconditionally true wherever SwiftNIO is present. What drops out where it is absent: the `eventLoop` property, the `execute(sql:_:) -> EventLoopFuture<Void>` requirement and its default bridge to `async`, the `EventLoopFuture` variants of `SQLQueryBuilder.run()` and of the `SQLQueryFetcher` `first`/`all`/`run` families, the NIOCore re-exports, and the deprecated `SQLBenchmarker` future bridges. Each `#if` encloses the doc comment of the declaration it gates rather than sitting between the two. A `#if` in that position detaches the comment: the declaration still compiles, but the symbol graph reports it as undocumented, so the published API docs lose the entry with no build-time diagnostic. Placed correctly, the doc comments are byte-identical to before. Result: Wherever SwiftNIO is available the public API, the documentation and the symbol graph are unchanged. `swift build --target SQLKit -Xswiftc -emit-symbol-graph` emits the same symbols with the same `docComment` line counts as before, and `diagnose-api-breaking-changes` reports no differences. Where it is absent the `async` surface — already the recommended API on every one of those calls — is unaffected and becomes the only one.
Motivation: SwiftNIO cannot be built for `wasm32-unknown-wasip1`, so SQLKit currently fails to configure for that platform at all — the failure is in dependency resolution, before any of the conditional sources in the previous commit get a chance to matter. 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; the suite exercises the `EventLoopFuture` API and is not run on WASI. 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.
scottmarchant
force-pushed
the
feat/wasi-nio-free
branch
from
July 29, 2026 03:24
84ba06c to
f008acf
Compare
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
1 participant
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.
Builds SQLKit on
wasm32-unknown-wasip1without SwiftNIO. Embedded Swift is out of scope and stacked separately as #4 (including theSQLBindabletypealias, the one part that needs real discussion), which keeps this diff small.Changes:
EventLoopFuturesurface goes behind#if canImport(NIOCore):SQLDatabase.eventLoop, the future-returningexecute(sql:_:)requirement and its default bridge,SQLQueryBuilder.run(), the threeSQLQueryFetcherfuture families, the NIOCore re-exports, andSQLBenchmarker's two deprecated bridges. Theasyncsurface, already the recommended API at every one of those call sites, is untouched and is all that remains where SwiftNIO is absent.NIOCore(and the test target'sNIOCore/NIOEmbedded) with.when(platforms: nonWASIPlatforms), the same spelled-out-list idiom as Add support for WASILibc apple/swift-nio#2671 and swift-crypto, with a comment pinning the list to the manifest's tools version.Where SwiftNIO is present, nothing changes: every gate is unconditionally true, and
swift package diagnose-api-breaking-changesreports no breaking changes in SQLKit or SQLKitBenchmark.Verification:
swift buildandswift test: green, suite untouched at 169 tests, including with CI's--explicit-target-dependency-import-check error -Xswiftc -require-explicit-sendable.--swift-sdk swift-6.3.1-RELEASE_wasm): green, zero SwiftNIO object files, no NIO symbols in the built objects.SQLKitBenchmarkstill builds for regular WASI.with_wasm: truetovapor/ci(the wasm check skips drafts).Notes for review: every gate is a capability gate (
canImport), inSources/only, never in a manifest; there is noos(WASI)anywhere. All three packages in this stack gate the same modules on the same condition, and a package that did build NIOCore for WASI would fail loudly at compile. No SwiftPM traits, no versioned manifest, no tools-version bump, no new dependencies.Base
base/vapor-mainis an exact snapshot of vapor/sql-kit@main at 11ed591 (PassiveLogic/sql-kit@main is byte-identical, so there is no fork drift). Rebasing onto the realvapor/mainis a no-op.