Is the use of `wasm-pack` still recommended in the document?

[Spxg]

wasm-pack will no longer be maintained by us, the wasm-bindgen document still recommends using wasm-pack for building and testing, I think this needs an update.

wasm-pack has its own document: https://drager.github.io/wasm-pack/book

[daxpedda]

I believe wasm-pack fulfills two purposes for us:

1. Configuration-free usage with cargo. E.g.cargo run, cargo test and such.
2. 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-pack in my opinion. But we might consider holding off on that until we have a replacement in place.

[Spxg]

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 maintaining wasm-pack is the best option.

[daxpedda]

Yeah the idea is that it would be maintained by us.

Personally I'm not keen to maintain wasm-pack as 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 current wasm-pack maintainer and see where we land.

This might be something we want to discuss in more detail at a meeting.

[RReverser]

FWIW the idea of https://github.com/wasm-bindgen/wasm-bindgen/issues/4621 is exactly as a replacement for wasm-pack. If we built that linker wrapper, we'd get even better integration with Cargo features (e.g. workspaces) "for free".

[daxpedda]

I think its still worth to explore a cargo-* binary to make it truly configuration-free. Apart from the whole JS ecosystem integration wasm-pack provides, that we probably don't want to add directly into the linker.

[RReverser]

Apart from the whole JS ecosystem integration wasm-pack provides

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. 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 test but that's not really JS ecosystem integration?

[RReverser]

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.

[daxpedda]

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 pack does. But just the regular output of wasm-pack build includes more .js files, a package.json and more wasm-bindgen doesn'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.

[RReverser]

But just the regular output of wasm-pack build includes more .js files, a package.json and more wasm-bbindgen doesn't do.

package.json yes, but there shouldn't be any extra .js files.

[RReverser]

I'm talking about the stuff wasm-pack pack does.

These are thin wrappers around npm pack / npm publish, not very interesting to most users.

[daxpedda]

But just the regular output of wasm-pack build includes more .js files, a package.json and more wasm-bbindgen doesn't do.

package.json yes, but there shouldn't be any extra .js files.

Oh, just looked at it, I think that's just the regular bundler output that I never use.

I'm talking about the stuff wasm-pack pack does.

These are thin wrappers around npm pack / npm publish, not very interesting to most users.

I think the point still stands. wasm-pack does way more then we need. All the tool installation options, the nice CLI output, cargo-generate integration, npm publich comes with a bunch of small stuff like logging in, rustup integration, the list goes on and on.

In no way I want to diminish wasm-pack here, I'm just saying it came from a time were much more maintainer resources were available.

[RReverser]

Oh yeah I agree, that's why when rustwasm was being split up, we didn't ask for wasm-pack to be moved to this org, but @drager asked for it to be transferred to them instead.

[nickbabcock]

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-opt of a single wasm artifact. If a project has multiple Wasm bundles, it's easier to achieve better build times with a single cargo build and 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.

[RReverser]

@drager Are you still intending to work on wasm-pack? Would you be interested in joining our next maintainer meeting to chat?

[extraymond]

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.

[drager]

@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) :)