Automatically generate Swift bindings for TypeScript declarations

[MaxDesiatov]

IDK if carton is the most appropriate place to implement the generation, but I think it could provide at least some helpers to make things work smoothly.

One part of this could be a SwiftPM build tool, which reads a config that specifies a path to .ts and .d.ts files and generates Swift source files providing type-safe wrappers based on this.

[j-f1]

I think this would be best done as a separate tool (maybe written in TS?) so that it could be easily integrated into a webpack/esbuild/etc dev server. Then if there’s a carton dev command elsewhere, it could pick up the updated Swift bindings using the standard watch mode.

[j-f1]

Also, from my experience, the TypeScript compiler API provides a ton of functionality in terms of extracting details about types, but it is totally undocumented. Here’s some code I wrote in 2019 that could be a good starting point: https://github.com/denoland/registry/blob/5ec3aa9d853923cf36c19a3d9b58795589cc0ca4/src/analyze_code.js

[MaxDesiatov]

Is there any indication for how stable this API is? One concern could be that it's unstable if it's undocumented, and this quite probably will cause us headaches in the future due to potential breakages.

[j-f1]

It seems fairly stable, judging based on the log of breaking changes: https://github.com/microsoft/TypeScript/wiki/API-Breaking-Changes

[j-f1]

In terms of DX, my first thought is that you would provide a list of .ts/.d.ts files as input, and each would be turned into its own Swift module. That way users could make a file that simply re-exports all of the types they want to use in Swift (although we’d need to pick up dependencies somehow). Some things to think about:

• classes. WebAPIKit only works because all of the relevant class constructors are on the global. We’d need to have some sort of glue code to make non-global classes available to Swift
• interfaces. TypeScript uses duck typing, which would be slow for Swift to verify. But if our users are willing to trust TypeScript, I guess we could just wrap any JSObject without doing type checks.
• unions, especially between interfaces. The standard practice in TS is to use a “discriminated union” (i.e. one key like type tells you which case of the union a given object is). I don’t know if the TS API gives us enough information to auto-generate discriminators, but either way this will be both non-trivial and super important to get right if we want to let people access arbitrary TS code.
• Currently, WebAPIKit only supports attaching functions to global classes. How could we most ergonomically support users providing their own imported functions (without them having to deal with manually encoding JSValues)?