Cannot import FoundationNetworking

[Sajjon]

How can I use URLSession? I tried importing FoundationNetworking but I can't get it to work.

I use:

swift --version
SwiftWasm Swift version 5.3 (swiftlang-5.3.0)
Target: x86_64-apple-darwin19.6.0

And compilation command: swift build --triple wasm32-unknown-wasi

main.swift:122:35: error: 'URLSession' is unavailable: This type has moved to the FoundationNetworking module. Import that module to use it.
    private lazy var urlSession = URLSession(

So then I try:

import Foundation
import FoundationNetworking

// ... later
let urlSession = FoundationNetworking.URLSession(
        configuration: .default,
        delegate: self,
        delegateQueue: nil
)

But that results in

main.swift:4:8: error: no such module 'FoundationNetworking'
import FoundationNetworking

So then I try:

import Foundation

#if canImport(FoundationNetworking)
import FoundationNetworking
#endif

But that results in:

main.swift:122:35: error: cannot find 'FoundationNetworking' in scope
    private lazy var urlSession = FoundationNetworking.URLSession(
                                  ^~~~~~~~~~~~~~~~~~~~

[MaxDesiatov]

Thanks for creating the issue @Sajjon. I've updated the SwiftWasm book chapter about Foundation to explicitly mention FoundationNetworking as unsupported. The reason is that browsers (and currently WASI too) don't provide access to raw sockets, which is what libcurl (and Swift NIO as a potential replacement for libcurl) requires, and FoundationNetworking is built upon those.

If making HTTP requests is something you're looking for, I recommend checking out OpenCombineJS, which can convert JSPromise instances returned from the fetch browser API to proper OpenCombine publishers, and those are easier to interact with.

Does that resolve your issue?

[Sajjon]

Thanks your prompt reply! I was hoping to have a complete Swift codebase (with networking in place) that I could just compile to WebAssembly using SwiftWasm.

So your suggestion is not a feasible solution for me, and looks like I won't be able to achieve my goal just yet. Hopefully networking matures in WebAssembly land (and thus becomes ready for use with SwiftWasm).

I applaud all your efforts with the SwiftWasm project, it really is amazing! Imagine Swift possibly someday being the language "of the web" 😍

[Sajjon]

Will close this issue for now, thanks!

[MaxDesiatov]

Hopefully networking matures in WebAssembly land

This is not a problem specific to WebAssembly, browsers have to implement a raw socket API first so that we can bridge it. There's nothing that prevents us from bridging it to WebAssembly if browsers supported this.

I applaud all your efforts with the SwiftWasm project, it really is amazing! Imagine Swift possibly someday being the language "of the web" 😍

Thanks, I appreciate it! I think we're very close to it, we're working hard on improving libraries and tooling to achieve that.

[Sajjon]

This is not a problem specific to WebAssembly, browsers have to implement a raw socket API first so that we can bridge it. There's nothing that prevents us from bridging it to WebAssembly if browsers supported this.

Ah, ok thanks! Sorry, I'm a complete web and WASM n00b so I have difficulties distinguishing between what's what and how each entity relate to an another (Swift, SwiftWasm, WebAssembly, Wasmer, Browsers...) 🤪

Btw, how close do you think we are for Apple to accept the work being doing in this Swift fork? And adopting SwiftWasm in the upstream (github.com/apple/swift)? Like 6 months, 1 year, 2 years? Impossible to say with accuracy of course, but what is your personal guess @MaxDesiatov ? :) Because the other day I saw that the Apple Documentation for Platform in SPM includes wasi!

[j-f1]

While it wouldn’t be possible to use FoundationNetworking as-is, it should be possible to implement at least some of its (HTTP-based) APIs by wrapping JavaScript’s fetch API.

[MaxDesiatov]

Possibly, but the problem is that Foundation is a "core" library that's part of the SDK distributed with the toolchain. We'd need to do the same for JavaScriptKit, which is blocked by swiftwasm/JavaScriptKit#61.

There is also the runtime part of JavaScriptKit, which we currently distribute in carton. We need to find a way to distribute that together with the Swift part of JavaScriptKit, as they need to be of the same version to avoid breakage.