Migration to TypeScript (2026)#8826
Conversation
post.js converts statically-defined members into instance members, but hides the static ones from public API. The deprecations can be deleted.
- `repository.url` was missing "git+" - adds "prepublishOnly" script - updates "files" field to include `./build/` - `package.json` is included by default - `package-lock.json` is excluded by default
|
@chharvey you need to fix the build before any review can take place |
|
Also, I'm a bit surprised that you present this PR as your sole contribution ? |
|
@ericvergnaud My intention was not to take all the credit, and i apologize if that's how it's perceived. I did give you a shout-out in my opening message in #8656 and mentioned that the work you did was the spark and inspiration behind my proposal. When i first checked out your branch my initial goal was to propose a PR with modifications into it, but it was far behind the latest Anyway i realize you did contribute a lot of effort to the TS development side of things and i don’t want that to go unnoticed, so my thanks goes to you for taking initial action. I’m looking forward to any constructive feedback you might have on this PR; if you have any suggestions to apply from your branch then i'm more than happy to accommodate. I'm hoping we can work together to finalize this effort and continue to provide TS maintenance as the Binaryen C++ codebase evolves. |
|
It's not "how it's perceived", it's how it "is": none of my commits, not a single mention of my work. |
I didn't take @chharvey 's actions that way. In this project we always squash when merging to But I definitely agree that there should be shared credit. @chharvey perhaps add that to the description of this PR? When we squash, we usually use the description of the PR as the commit message. So that would ensure proper credit. @ericvergnaud would that address your concern? |
|
~11k is huge for one PR. And I agree with @ericvergnaud. Why not just break whole task into a few independent PRs, map out the dependencies and ownership, and then land them incrementally? That should make reviews and coordination much easier. Ideally, keep each PR under ~2-4k LOC where possible. |
| } | ||
|
|
||
| return { | ||
| /** @experimental */ |
There was a problem hiding this comment.
It's not experimental, It's already standartized in wasm 2.0
|
|
||
|
|
||
|
|
||
| const EXPRESSION_TYPE_REGISTRY: ReadonlyMap<ExpressionId, new (expr: ExpressionRef) => expressions.Expression> = new Map<ExpressionId, new (expr: ExpressionRef) => expressions.Expression>([ |
There was a problem hiding this comment.
using new Map for remapping ExpressionId => ExpressionRef is huge overhead and unnecessary in my opinion. You can you plain object, sparce array, switch but better ti avoid all of this compleately if possible using different architecture decision based on some id-gen invariants
4 participants
Hello Binaryen team,
This PR starts a significant effort to migrate the JS API to TypeScript!
There's already an ongoing open discussion: #8656. Anyone is more than welcome to join and voice their thoughts.
For any non-JS developers, TypeScript is a type-safe superset of JavaScript that attempts to catch errors at compile-time rather than at runtime. I believe it brings many benefits to a project like this, including:
TypeScript typings have been maintained separately by the AssemblyScript project, which means they drift out of sync as Binaryen evolves. This PR brings the typings and the implementation into the same codebase so they are always in sync. In other words, JavaScript development is now just TypeScript development.
Aside from the general benefits of TS, this effort also reorganizes the codebase into a more logical structure rather than having everything in one monolithic file. This makes the code easier to navigate, maintain, and contribute to.
In this PR, I haven’t touched any of the original JS code (
/src/js/binaryen.js-post.js) or the existing tests, but instead copied it into a completely new TS codebase at/ts/. If my proposal is accepted, my plan is to phase out the existing code and tests little by little, making sure there are no breakages in the process. That'll probably look like more incremental PRs in the future instead of combined into one giant one.For examples and development guide, see the
/ts/README.mdfile. I also got started on migrating a handful of tests, but they can wait for another PR.Under the hood, the biggest architectural change is how the TypeScript layer integrates with the Emscripten build. Currently, the post.js file is appended directly to the Emscripten output via the
--post-jsflag and the entire thing is compiled together into a single bundle. In my approach, Emscripten first builds and bundles the WASM bindings into an artifact which is then imported and wrapped by the TS. This decouples WASM binding generation from TypeScript API development, meaning the two can evolve independently without requiring a full rebuild every time the TS layer changes. It also makes the TypeScript layer independently testable and debuggable. Users can step through the code without having to navigate a minified bundle.There are several other important changes I've made to the API, which I think more intuitively organizes the code and creates a more predictable access surface. The API Overview doc, specifically the deprecations section, gives a high-level overview. For the complete API generated from code, see the docs hosted on gh-pages of my fork. If anyone has strong opinions, I'm open to suggestion. We want both developers and users to be happy.
Some open questions, which we can discuss either here or in #8656.
/ts/folder. Is that where it should stay? How do the Binaryen repo owners prefer to organize the code?/docs/binaryen.ts/from the root level, but this is only to get thegh-pagesbranch to work. (Ideally they'd live alongside the TS source code.) If we decide to publish docs elsewhere, they can be moved.binaryen.tsregistered at https://www.npmjs.com/package/binaryen.ts, if we decide to stick with it. New contributor permissions can be added if needed.I'm hoping this can make a positive impact on the long-term health of the project, and I'm committed to carefully following through. All feedback is appreciated, and thank you!