Generate JavaScriptKit `.js` runtime with SwiftPM build tool about javascriptkit HOT 6 OPEN

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.

from javascriptkit.

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

from javascriptkit.

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).

from javascriptkit.

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.

from javascriptkit.

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.

from javascriptkit.

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.

from javascriptkit.