Compiling a TS Project with many moving pieces

[Fancy2209]

Hello, I stumbled upon this and I am curious, how hard would it be for one to be able to add support for compiling a big project, like https://github.com/awayfl/awayfl-player , to WebAssembly and Native Targets with this?

[ASDAlexander77]

Sorry for the very late reply.

Short answer: compiling a project like awayfl-player as it is would be a large porting job, not a build-flag change. Here is what works today and where the hard parts are.

What works for big projects

• Many files and modules. Imports across files work. A project can be split into shared libraries (--emit=dll), or compiled file by file with --emit=obj and linked. There is also CMake support: .ts is a CMake language (TSLANG), with incremental rebuilds.
• A real-world example. native_ts_graphics is 25 Direct3D 12/Vulkan samples (ray tracing, meshlets, compute…) written in TypeScript, compiled with tslang and linked with a C++ engine. It runs on Windows and Android. Porting it turned up about 28 compiler bugs, all of them fixed now. That is roughly the process a large project goes through.
• Native targets. Windows (x64, x86), Linux x64, Android (arm64, armv7, x86_64), and WebAssembly (-mtriple=wasm32-unknown-unknown).

Where awayfl-player would be hard

1. Browser APIs. tslang compiles TypeScript ahead of time to native code. There is no JavaScript engine and no browser underneath, so there is no DOM, canvas, WebGL, Web Audio or fetch. A player built on those would need each one replaced by bindings to a native library (OpenGL/Vulkan, SDL, an audio library…) through declare function, the way native_ts_graphics binds its C++ engine. For WebAssembly you would write those as JS imports yourself; nothing is generated for you.
2. Dependencies have to be TypeScript source. npm packages shipped as compiled .js can't be compiled; tslang needs the .ts sources of everything it builds. The awayjs packages are TypeScript, which helps, but every third-party JS dependency would need a replacement.
3. Dynamic JavaScript idioms. Code is compiled from its static types. Patterns that rely on the JS runtime, such as editing prototypes, eval/new Function, or adding properties to objects at run time, don't compile or behave differently. Code that is cleanly typed works well. A Flash player that emulates ActionScript's dynamic objects will probably lean on these patterns in places.
4. Memory. The default is a garbage collector (-mm=gc). There are also reference counting (-mm=rc) and compile-time single ownership (-mm=own). The documented WebAssembly build uses -mm=none, which never frees memory, and that doesn't suit a long-running player.

How I'd approach it

Start with one self-contained package from the bottom of the dependency tree, such as a core/geometry package with no browser dependencies, and compile it with tslang. Then fix or report whatever fails and move up the tree, putting a native backend behind the rendering and audio interfaces. If you or anyone else tries this, please open issues with complete repros. That is how the native_ts_graphics port got to working.