New TypeScript Effort

[chharvey]

Hey WASM team,

I’m excited to get to work on a new effort to migrate JavaScript to TypeScript. I want to first give a huge shoutout to @ericvergnaud for doing most of the coding and laying the groundwork (see #6192). Using that as a starting point, I want to modernize the code and simplify the workflow for developers writing TS.

I’m hoping that this can serve as a single source of truth where the JS wrapper and TS typings are combined into one. When WASM adds new features, the JS and TS get updated together. Hopefully that will open a bottleneck to TS development.

There are two major restructures I had in mind:

• More modular code. Instead of all the code living in one giant file, I want to split it into manageable chunks. ES Modules is the way to go, seeing as ES2015 was released 10+ years ago. Once we have our modules, a bundler can put it all together for the post-js build.

• Nominal types. Because everything is a number in the current TS declaration file, you don’t get yelled at when you accidentally assign an i32 to an i64. That means you might have to wait until you run your tests before getting any errors, and that’s hoping you have 100% coverage. What we’d like is TypeScript to differentiate between expression types during static analysis. Nominal types can do that; though they’re not a built-in feature of TS, we can ‘hack’ them by using type intersections. See my comment here as an example. Of course, this takes a backseat to the TS migration. Once that’s complete, we can focus on optimizing the typings.

I already got started on some of this work. I created a top-level /ts/ directory, which is a full-fledged Node module, with a package.json and everything. The hope is that we can publish it to NPM as a stand-alone package, and it would essentially replace AssemblyScript’s current package. (No hate, they’re doing great over there, but there’s not been a lot of attention to the TS declaration file, and it tends to fall out of sync with WebAssembly’s JS bindings.) I started my work in a new fork — check it out.

Thanks to you all for your tireless and continued work. Even as a new contributor, I see a lot of potential in WebAssembly and want to give its designers/developers any support that I can. Thank you!

[kripken]

Nice!

I wish I had time to work on this myself, and would be very happy to see it improve.

My main question here though is maintainability. The more we can automate such bindings, the easier it is to keep it working over time. That is why I was hoping something like the wasm-delegations-fields macros, or Embind's support for TypeScript, could be used, to avoid manually writing the bindings (as previously discussed - I find find the links later if you haven't already seen those). What do you think about that kind of thing?

[chharvey]

I’d have to look into it; I’ve never heard of Embind before. But something to mention is there isn’t always a one-to-one mapping of the C++ bindings and those in JS. For example, just something I came across today, Module#setMemory contains logic that goes beyond a simple call to the C++ library.

Not to mention the organization and nesting of methods, e.g. binaryen.i32, binaryen.i64, binaryen.getExpressionType, Module#i32.add, Module#i64.add, etc. These don’t all exist at a singular top level. So I’d imagine there’s still a bit of manual JS development to be done. This is an effort just to make it so that JS development becomes TS development.

[kripken]

Yeah, I guess it can't be fully automated. I still hope part of it can, but I guess we only need to keep that in mind as an idea. We can move forward without it, from my point of view.

[ericvergnaud]

Hey!
I would also love to see this progress, and I find your ideas useful.
IIRC what became blocking when I tried making things happen was governance.
@kripken has there been any progress in that area?

[kripken]

I think we resolved governance issues? See

#6225 (reply in thread)

After that meeting I think we were all on the same page, leaving just technical issues. Unfortunately, the technical issues in the paths I tried turned out to take too long for me to be able to get into them. But if we find a better solution, or someone has time for this, I think we can move forward.

[ericvergnaud]

So in short, we reached an unachievable agreement? Sorry if the above sounds a bit harsh, but that is a governance issue. From the beginning, the issue stems from people with plenty of goodwill producing JS/TS as a nice and cheap side-effect of doing something more important to them. I was not supportive of the automated binding mechanism, but had no reason to stop it - nobody wants more manual work. Turns out that manual work (which is already 99% done) might be the best path, because it can be maintained by people who have interest in it… At this point I suspect the only path forward is the following: - create an independent repo for the ts/js binding, that uses binaryen. If at some point in the future WebAssembly wants to own it, we’ll transfer the ownership. - we’ll publish the package under some convenient org until WebAssembly takes ownership How does that sound?

…

Le 30 avr. 2026 à 20:13, Alon Zakai ***@***.***> a écrit : I think we resolved governance issues? See #6225 (reply in thread) <#6225 (reply in thread)> After that meeting I think we were all on the same page, leaving just technical issues. Unfortunately, the technical issues in the paths I tried turned out to take too long for me to be able to get into them. But if we find a better solution, or someone has time for this, I think we can move forward. — Reply to this email directly, view it on GitHub <#8656 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZNQJBNU73LTPFOOPT5EKT4YOJVHAVCNFSM6AAAAACYKDCSN2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNZXGI4DIOI>. You are receiving this because you were mentioned.

[kripken]

Now I see what you mean, good point (I thought you meant "governance" as in "which repo" which was also an issue before). Yes, what you say is a fair criticism. Apologies for not doing better here.

Ok, let's try to fix things. I'm ok with the manual approach, if the people motivated to work on this prefer it. It can be here in the Binaryen repo, following our usual review rules, that is, if we have a reviewer. (I can try to find time to review too, but it would be faster if we have someone else)