feature: allow wasm-bindgen to work on emscripten targets (INCOMPLETE/RFC)

[durin42]

We've got this wired up on our internal build system and wanted to try and get feedback before we get further. With our internal build system we've got this working end-to-end, and we're happy to do work here to make sure the right things happen with cargo including for cargo test. The question right now is: are y'all open to this landing if we're doing the work, or is this completely out of scope for what you want in the project?

(I've seen some other conversations about this in old bugs, but don't know the current direction of the project.)

Thanks!

[durin42]

@daxpedda could you let me know if this is a viable direction, or something we wouldn't be able to land? Like I said, we're happy to do the work, but don't want to spend the time if emscripten support will be rejected.

[daxpedda]

Similar things have been discussed about WASI here as well, see #3454.

In general I'm not against Emscripten support, but I'm not particularly in favor of it either. My understanding is that it should be possible to stick with wasm32-unknown-unknown and consume Emscripten dependencies (e.g. C/C++). Anything that helps that along I'm happy to improve on. But this isn't a reason to block support, just explains the lack of driving force behind it.

On the other hand I have so little knowledge about Emscripten that I honestly would be unable to form a qualified opinion here and I'm not interested in diving into it. So this needs a different maintainer!

[walkingeyerobot]

Hi! I’m an Emscripten contributor and a co-worker of @durin42’s, and we have a strong need to get wasm-bindgen and Emscripten to play nicely together. More specifically:

• We have Wasm applications primarily written in C++.
• These need to be able to depend on Rust libraries.
• These applications use Emscripten bindings to talk to JS.
• Third party Rust libraries included by these applications want to directly use JS independently of how it’s being used by the larger application. This is the reason we aren’t just running everything through C++.

My tentative plan is to have Emscripten invoke wasm-bindgen and then incorporate wasm-bindgen’s JS into the Emscripten JS. This will require wasm-bindgen to:

1. Accept Wasm that has targeted wasm32-unknown-emscripten (which is what this PR does)
2. Have wasm-bindgen emit an Emscripten-style JS library for direct integration into the rest of Emscripten’s JS. This would be a new option on wasm-bindgen’s existing --target flag.

This will also require a plethora of Emscripten changes. I’ve spoken with Emscripten owners, and they’re on board with this plan. I plan to make changes to both projects in branches, and once I have something that at least partially works, I can open some draft PRs to gather feedback. That also means we don’t immediately need to have this merged if you prefer; we can wait until we’re a bit further along.

[daxpedda]

That also means we don’t immediately need to have this merged if you prefer; we can wait until we’re a bit further along.

Especially for adding a new target, waiting until there is some consensus is very desirable.

---

Otherwise my last comment (#4014 (comment)) still reflects the current stance.

[walkingeyerobot]

Sounds good, I'm happy to gather consensus. I'll start putting together a proof of concept in the next few weeks so we have something more tangible to discuss.

On the other hand I have so little knowledge about Emscripten that I honestly would be unable to form a qualified opinion here and I'm not interested in diving into it. So this needs a different maintainer!

To clarify, are you looking for another current maintainer to lead the discussion here? Or are you looking for me to commit to maintaining this feature long-term after it's written? If the latter, I'm happy to agree to that. I'll be sure to have good test coverage and make myself available to address any issues / PRs / etc. that pop up down the road.

[daxpedda]

To clarify, are you looking for another current maintainer to lead the discussion here? Or are you looking for me to commit to maintaining this feature long-term after it's written?

I was looking for another current maintainer to take over here, but I'm very happy to accept target-specific maintainers as well.

If the latter, I'm happy to agree to that. I'll be sure to have good test coverage and make myself available to address any issues / PRs / etc. that pop up down the road.

That would be great!