Repository navigation
Is the use of wasm-pack still recommended in the document? #4634
Description
Activity
I believe
wasm-packfulfills two purposes for us:- Configuration-free usage with
cargo. E.g.cargo run,cargo testand such. - Integration with the JS ecosystem, e.g.
webpack(I know next to nothing about that)
Considering its not maintained by us and maybe unmaintained, I believe we should not recommend it either way. But we need an eventual replacement for our users as well, at least for 1., I will leave talking about 2. to others with actual knowledge about this topic.
Without going further off-topic: we should remove all mentions of
wasm-packin my opinion. But we might consider holding off on that until we have a replacement in place.- Configuration-free usage with
until we have a replacement in place
This replacement needs to be maintained by us or someone can guarantee long-term maintenance? Considering the functionality and popularity of
wasm-pack, perhaps maintainingwasm-packis the best option.Yeah the idea is that it would be maintained by us.
Personally I'm not keen to maintain
wasm-packas the last time I looked at it, it seems to have a much larger scope then I would prefer. But if we decide its pretty much what we would try to do anyway, maybe we can reach out to the currentwasm-packmaintainer and see where we land.This might be something we want to discuss in more detail at a meeting.
I think its still worth to explore a
cargo-*binary to make it truly configuration-free.
Apart from the whole JS ecosystem integrationwasm-packprovides, that we probably don't want to add directly into the linker.Apart from the whole JS ecosystem integration
wasm-packprovidesI'm not sure what you're referring to there tbh. I don't think it does anything special to JS+Wasm aside from building with Cargo and running wasm-bindgen. It does some extra nice things like checking Cargo.lock to see which version of wasm-bindgen to download, or invoking the test runner when you do
wasm-pack testbut that's not really JS ecosystem integration?I'm not sure what you're referring to there tbh. I don't think it does anything special to JS+Wasm aside from building with Cargo and running wasm-bindgen.
I'm talking about the stuff
wasm-pack packdoes. But just the regular output ofwasm-pack buildincludes more.jsfiles, apackage.jsonand morewasm-bindgendoesn't do. No idea what all this is or includes.If we do want Cargo wrapper, we might as well stick to wasm-pack - @drager asked to transfer it to themselves recently because they were keen on maintaining it - and wasm-pack is unlikely to go anywhere soon, given how many projects depend on it.
As long as its maintained I'm fine with it. If not, I would like to offer a lighter version that we can actually maintain.
But just the regular output of
wasm-pack buildincludes more.jsfiles, apackage.jsonand morewasm-bbindgendoesn't do.package.jsonyes, but there shouldn't be any extra.jsfiles.I'm talking about the stuff
wasm-pack packdoes.These are thin wrappers around
npm pack/npm publish, not very interesting to most users.But just the regular output of
wasm-pack buildincludes more.jsfiles, apackage.jsonand morewasm-bbindgendoesn't do.package.jsonyes, but there shouldn't be any extra.jsfiles.Oh, just looked at it, I think that's just the regular
bundleroutput that I never use.I'm talking about the stuff
wasm-pack packdoes.These are thin wrappers around
npm pack/npm publish, not very interesting to most users.I think the point still stands.
wasm-packdoes way more then we need. All the tool installation options, the nice CLI output,cargo-generateintegration,npm publichcomes with a bunch of small stuff like logging in,rustupintegration, the list goes on and on.In no way I want to diminish
wasm-packhere, I'm just saying it came from a time were much more maintainer resources were available.Yeah recommending wasm-pack is tough:
- The wasm-opt installed by wasm-pack suffers from major performance issues on linux. Projects should pin to a more recent version of binaryen or skip the wasm-opt step
- Lack of custom cargo profile support. The feature was merged 10 months ago, but is unreleased
- The autogenerated package.json is nearly never what you want. Either you are better off with a handcrafted package.json or one isn't necessary. By extension, the wasm-pack packaging and publishing becomes fruitless.
- Lack of parallelism. Wasm-pack is geared towards a serial pipeline of
cargo build+wasm-bindgen+wasm-optof a single wasm artifact. If a project has multiple Wasm bundles, it's easier to achieve better build times with a singlecargo buildand fan out bindgen and optimization.
While it would be nice to have an additional mechanism to keep wasm-bindgen-cli in sync, the error message when they deviate seems like a good enough stop-gap.
Reacted by AⱯI see the above discussion were more about from the perspective of the rust wasm author, which many valid points are raised. I mostly agree that wasm-pack may not be mandatory for creating modules from rust.
However, as a developer that shared packages to my colleagues, I think wasm-pack made consuming the generated package much more easier for the other part of the world(npm land)
for example a pattern which I often uses is to configure the generated output to be at another git repo's submodule, so that it can directly reference the wasm-powered package in npm without interrupting their flow. and the js dev are now hands free for consuming the compiled artefact reliably, with the premise of npm workspace and pnpm, this is further useful where a core wasm-powered subpackage is wrapped or referenced inside a user-facing js package
If we were to remove mentioning wasm-pack in document, and were a js developer curious about how they can integrate a wasm module in their repo, they now have to at least figure out how to generate the artefact.
I see this as a point of friction since wasm-pack also made the cli command to align better with the npm command. So when a js developer try to invoke the build command through wasm-pack, they may feel more encouraged and more familiar with some of the term used in the cli help msg.
- added 2 commits that reference this issue
on Nov 4, 2025 @drager Are you still intending to work on wasm-pack? Would you be interested in joining our next maintainer meeting to chat?
@RReverser Sorry for my lack of presence, I intend to maintain wasm-pack, but I only spend my limited free time on it currently, unfortunately... I would be up to join any meeting (depending on when it is) :)
wasm-packwill no longer be maintained by us, thewasm-bindgendocument still recommends usingwasm-packfor building and testing, I think this needs an update.wasm-packhas its own document: https://drager.github.io/wasm-pack/book