Generate JavaScriptKit `.js` runtime with SwiftPM build tool

[MaxDesiatov]

I'm proposing to declare Runtime/lib directory as SwiftPM resource as described in SE-0271. With a few adjustments to carton, this will allow us to separate carton entrypoint files from JSKit runtime files, and simplify our release process as well. The end result would be that we can simply tag a new JSKit release without a need to update carton entrypoints and tag a new carton release each time.

The complication is that we need to keep .js files in Runtime/lib fresh and in sync with the .ts source files. I'm currently investigating whether SwiftPM build tools proposal can help us generate .js files at SwiftPM build time. While rollup.js requires Node.js to be installed to work, I'm looking at using swc.rs as a build tool, as it provides self-contained binaries for all most popular platforms. Bundling and minification with SWC is still marked as unstable, but with ES6 modules supported in all recent browsers, I wonder if we can keep JSKit runtime supplied in separate files, which could make it slightly easier to debug as well.

Bundling and minification of resulting .js files can then be left to the user, making it more flexible. As a future direction, rollup.js config could be supplied with carton, which it then could use when it runs carton bundle and detects that Node.js and rollup.js are installed and available on user's machine.

[j-f1]

Another option is esbuild, which has a path to downloading directly from npm without having Node installed. Something to be aware of is that neither swc nor esbuild support type checking, so there would have to be a GitHub Action to make sure things stay type-safe.

Avoiding compilation entirely is also very possible — we could switch to using plain .js files with JSDoc-based type annotations. One small caveat with this is that we would no longer be able to use enums as they are not a native JS feature (but there are plenty of alternate ways this could be handled).

[MaxDesiatov]

Ah, I forgot about esbuild. Could try that as well and see what's easier to use and better documented. I like TypeScript quite a lot, so would prefer to keep using it. As for type checking, you're right that GHA job would catch issues, and probably it's reasonable to expect that developers of JSKit have a proper TS compiler/type checker installed for the development process.

[MaxDesiatov]

Glad to see that esbuild supports bundling and minification. Maybe we could utilize that in carton bundle when detecting that esbuild is available in SwiftPM dependency tree as a build tool. I also find it somewhat better documented than SWC.

[kateinoigakukun]

Another option is to allow users to specify JSKit npm package version in package.json at the top of user code, then bundle it by carton bundle.

$ carton init
$ tree -L 2
.
├── Package.swift
├── README.md
├── Sources
│   └── MyApp
├── Tests
│   ├── LinuxMain.swift
│   └── MyAppTests
├── node_modules
│   └── javascript-kit-swift
├── package-lock.json
└── package.json

$ cat package.json
{
  "name": "MyApp",
  "private": true,
  "dependencies": {
    "javascript-kit-swift": "^0.14.0"
  }
}

This option doesn't solve the potential version mismatch problem between the runtime npm package and SwiftPM package, but we can reuse many parts of the existing JS ecosystem, and no need to sync ts artifacts.

[MaxDesiatov]

I think JSKit version mismatch and npm/JS ecosystem interaction are two separate topics. Both deserve to be solved, but in my opinion the version mismatch and release engineering issues are more pressing.

For now I'm inclined to try the SwiftPM resources approach first in my own branches and see how that works before submitting any PRs here.

I'm trying to get WebGL/WebGPU stuff fixed in WebAPIKit, but that's blocked by BigInt changes, and I'm tired of rebuilding carton entrypoints every time anything changes in JSKit runtime. Especially when I only want to try latest commits in JSKit main branch.

[MaxDesiatov]

Keeping this open until Swift 5.7 and SwiftWasm 5.7 are available with swiftlang/swift-package-manager#4306 included in those releases.

[kateinoigakukun]

Closing as we no longer use SwiftPM's resource feature by default