Proposal to Create SIG-TypeScript-Compilation

[xwang98]

SIG-TypeScript-Compilation's primary goal is to describe and refine a suitable solution for compiling TypeScript program to WebAssembly based on the Wasm GC proposal and executing it in both browser and standalone Wasm runtime. The scope of this SIG is limited to discussions about compiling TS to WebAssembly, the necessary runtime API (potentially defined as WASI) for supporting TS language features such as Any type, and exploration of how WebAssembly can grow to provide better support of dynamic languages natively.

[fitzgen]

Hello,

The TSC discussed this SIG proposal at our most recent meeting. We have the following feedback:

• The SIG must not fork the TypeScript language. This can be achieved by only supporting a strict subset of the language, or by ensuring that all language extensions (e.g. additions to the type system or standard library) are coordinated with the TypeScript core team and have a path to being upstreamed.

• Any non-standard engine extensions or runtime interfaces exposed to guest TypeScript Wasm binaries must enter a standards process (e.g. become standards-track WASI or core Wasm proposals). Any such extensions must not ship in production until they are on the path to standardization and are sufficiently stable.

We would like to see verbiage enshrining these requirements in the SIG's charter.

On behalf of the TSC, Nick Fitzgerald

[xwang98]

Thank you @fitzgen and TSC for the valuable comments! Just one question regarding to the words "ship in production" below, what is the exact definition?

Any such extensions must not ship in production until they are on the path to standardization and are sufficiently stable

[fitzgen]

@xwang98,

Thanks for your patience.

Thank you @fitzgen and TSC for the valuable comments! Just one question regarding to the words "ship in production" below, what is the exact definition?

The features should be behind an experimental flag (e.g. --enable-foo-proposal) and should not be enabled by default in any toolchain or runtime until the proposal reaches the equivalent of phase 4 in the WebAssembly standards process. Additionally, enabling the feature in production deployments should be strongly discouraged, with warnings about the experimental nature and the possibility of breaking changes at any point.

On behalf of the TSC, Nick Fitzgerald

[xwang98]

@fitzgen Thank you for the explanation!

I fully understand the motivation behind however I are not sure phase 4 is appropriate level as requirement. Looking at the proposals from WebAssembly and WASI and many level 3 and below proposals are implemented already, I doubt the suggested rules have been followed in the BA practices:

• https://github.com/WebAssembly/proposals
• https://github.com/WebAssembly/WASI/blob/main/Proposals.md

Additionally, the primary goal of SIG is for discussion and possibly creating some proposal. It doesn't mean necessary developing tools or runtime. I see such requirements are better for the projects under BA, rather than SIG.

[penzn]

• Any non-standard engine extensions or runtime interfaces exposed to guest TypeScript Wasm binaries must enter a standards process (e.g. become standards-track WASI or core Wasm proposals). Any such extensions must not ship in production until they are on the path to standardization and are sufficiently stable.

Would it be sufficient to simply state that any new APIs would be added via WASI proposal process?

I don't have a lot of experience within BA, but what is the scope of SIGs as opposed to proposals? From personal experience, other projects define SIGs as coordination venues rather than concrete proposals (CG's subgroups are a similar idea).

The features should be behind an experimental flag (e.g. --enable-foo-proposal) and should not be enabled by default in any toolchain or runtime until the proposal reaches the equivalent of phase 4 in the WebAssembly standards process. Additionally, enabling the feature in production deployments should be strongly discouraged, with warnings about the experimental nature and the possibility of breaking changes at any point.

I am confused by WebAssembly standards process reference, does this requirement derive from it? To my best knowledge decisions about flags and warning are left to the implementer, at the very least I can't find anything about it in CG docs (WASI process seem to now refer to CG process).

[ricochet]

@xwang98:

I fully understand the motivation behind however I are not sure phase 4 is appropriate level as requirement. Looking at the proposals from WebAssembly and WASI and many level 3 and below proposals are implemented already, I doubt the suggested rules have been followed in the BA practices:

That's a good point. The exact required level of standardization and stability might vary based on which standards body is involved, and the nature of the proposals. The TSC is happy to provide guidance on whether a lower level of stability is sufficient for specific proposals.

Taking a step back, the TSC, as well as the board, which we consulted last week, feel strongly that this SIG should work towards results that follow two key principles:

1. The language being compiled must truly be TypeScript, not some fork of it that's not fully compatible.
2. Any APIs or new instructions a runtime exposes to Wasm to make it a viable compilation target for TypeScript compilation must go through a standardization process, must achieve consensus in that process, and be sufficiently stable before they can be enabled by default in any runtime under the Bytecode Alliance's umbrella.

These principles directly follow from the BA's operational principles, and in particular the "How We Want to Work With Others" section.

Note that these principles are not specific just to this proposed SIG; we are applying them equally to all work under the BA umbrella, including other recently proposed SIGs.

Additionally, the primary goal of SIG is for discussion and possibly creating some proposal. It doesn't mean necessary developing tools or runtime. I see such requirements are better for the projects under BA, rather than SIG.

You're right that some of the above is about implementations. The SIG should however work in a way that makes it easy for any concrete implementations to follow these principles. Additionally, the SIG should ensure that all contributors to these projects are fully aware of these requirements.

---

@penzn

Would it be sufficient to simply state that any new APIs would be added via WASI proposal process?

[...]

I am confused by WebAssembly standards process reference, does this requirement derive from it? To my best knowledge decisions about flags and warning are left to the implementer, at the very least I can't find anything about it in CG docs (WASI process seem to now refer to CG process).

We explicitly don't want to further any ecosystem fragmentation. As such, we want to ensure that any work resulting from this SIG's activities targets more than just a single runtime. The best way to ensure this is to get consensus to not enable any required features by default until they're sufficiently far along in a standardization process such that they can be implemented by multiple WebAssembly runtimes.

Additionally, WASI isn't the only body to coordinate with for this work. Depending on the direction the SIG ends up taking, the WebAssembly CG itself as well as other standards bodies might become involved. Plus, if any changes to TypeScript as a language are required, close coordination with the TypeScript team will become necessary.

We (Till, Nick, and Bailey) on the TSC can assist in coordinating with the relevant groups.

---

On behalf of the TSC, Bailey Hayes @bytecodealliance/tsc

[xwang98]

@ricochet Thank you and TSC for positive response. I have a submitted a change for added paragraphs according to the discussion:

The SIG is not intended to fork the TypeScript language. This can be achieved by only supporting a strict subset of the language, or by ensuring that all language extensions (e.g. additions to the type system or standard library) are coordinated with the TypeScript core team and have a path to being upstreamed.

This SIG follows BA's common guideline as the TSC suggested: Any APIs or new instructions that a runtime exposes to Wasm must go through a standardization process, and achieve consensus in that process, and be sufficiently stable before they can be enabled by default in any runtime under the Bytecode Alliance's umbrella.

Please see if it works out all the concerns.

[penzn]

@ricochet I just wanted to make sure that a reference to W3C process doesn't lead to an implication that W3C has requirements about when and how features are released by implementations 😄 That said, setting rules of engagement here is completely up to BA and there is not need to mimic W3C in any way.

[fitzgen]

The TSC has accepted this proposed SIG! Thank you for your patience and help with tweaking the charter.

If you need a SIG-TypeScript-Compilation repository, we can create one for you. Otherwise, if you are fine with just meeting minutes for the meantime, that is alright as well.

We will create a Google Groups mailing list for you soon and share details once they are ready.

Please do the following two things:

1. Send a pull request to https://github.com/bytecodealliance/meetings detailing the meeting times, creating a directory for meeting notes, and advertising how to join and participate.

2. Send an email to the Bytecode Alliance contributors Google Group announcing the creation of the SIG after the above pull requested has been merged. Example

Thanks again!

On behalf of the TSC, Nick Fitzgerald @bytecodealliance/tsc