-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a project template for writing wasm libraries intended for use by JS #56
Comments
A while back I had started doing something called cargo-wasm and the idea was eventually use that for building stuff and wrapping the commands needed every time to do it/deal with all the weird manual stuff when setting things up. It might be possible to work out some stuff and create a small config, kind of like xargo does, and have it initialize a project based off it. I might have time to hack in a prototype Ideally I really wish |
There was talk between WG domain leads about creating templates for each of our domains in our meeting yesterday, so I think the winds are changing and we can get this to happen. |
I think I and many others would be happy. It's something stack does in Haskell that I really wish Rust already had. Either way this sounds good. |
this sounds like a great idea! it's a bit blocked on the packaging tool which is blocked on how JS deps are expressed in wasm. to build the packaging tool i have an example template that i'm already working on - so i can help complete this as the packaging tool work moves forward :) |
I think we can pursue an incremental approach, where we start without packaging integration and then add it when it's ready.
Awesome! |
We might consider having a few different templates here, e.g. pure Rust one, ** - Although my main focus with |
I think this is covered by https://github.com/rustwasm/wasm-pack-template! |
It should have
Cargo.toml
extern
declarations for those crates already insrc/lib.rs
#![no_std]
declarationpanic_fmt
handler that doesn't usefmt
ing infrastructure, for small code sizes by defaultcargo build --release wasm32-unknown-unknown && wasm-gc ... && wasm-opt ...
Open questions:
wasm-bindgen
? This seems like a good choice to me.wee_alloc
as the global allocator? This is much more opinionated, and is likely not the right choice in many situations, but in the library-for-use-by-JS scenario fairly likely to be a good choice.The text was updated successfully, but these errors were encountered: