Wasm-pack: Create a `wasm-pack` npm module that installs wasm-pack

[fitzgen]

💡 Feature description

Publish a wasm-pack package to npm that runs the new wasm-pack installers, so JS users can get wasm-pack setup with just npm i -g wasm-pack.

💻 Basic example

$ npm i -g wasm-pack
...
$ wasm-pack --version # and now wasm-pack is installed!
0.5.0

[ashleygwilliams]

i will reserve this name now!

[ashleygwilliams]

https://www.npmjs.com/package/wasm-pack/

[robertohuertasm]

Hey, I've just created an npm package that:

• installs Rust,
• installs wasm-pack,
• sets the nightly toolchain (for the moment),
• adds wasm32-unknown-unknown target
• installs cargo-generate for you.

At the moment it only supports Unix but I'm eventually supporting Windows too.

You can get the package (wasm-pack-npm) here and take a look at the repo here.

[fitzgen]

@robertohuertasm awesome! I think it would make sense, once you have windows support and feel the package is in a good spot, to send a PR that embeds the package somewhere like wasm-pack/npm-package in this repo.

[robertohuertasm]

I've just added Windows support but I would like to test it a little bit more. I was thinking about adding a new command to it in order to generate a new wasm project from a template but I think that this could be something that wasm-pack should offer by default so nobody had to remember the url of the repo where the template lives whenever they want to use cargo generate. IMHO, I think this would make it even easier for people to start with wasm.

Regarding the PR, I'll be glad to make one whenever you want. I guess I'll have to deprecate my package once the new one is in place. By the way, does the team have a scope or an org in npm?

[robertohuertasm]

FYI: I've found some issues with the Windows installer in other PCs so it seems Windows is not available yet (unless the user uses the linux sub-system).

[fitzgen]

• installs Rust,

• installs wasm-pack,

• sets the nightly toolchain (for the moment),

• adds wasm32-unknown-unknown target

• installs cargo-generate for you.

Somehow I missed that the npm package you were working on does all of these things. I think we should cut back the scope of the npm package so that it doesn't duplicate work that wasm-pack already does (adding the w32-u-u target), do things that will become unnecessary in one week (force nightly rust).

Instead, I think we should just install wasm-pack and that's it.

We don't want to hide cargo and rustup et al from users, since they are core tools for rust hacking. That isn't to say that you were implying we should hide them from users, I'm just braindumping right now. I could also imagine a world where wasm-pack would install rustup users if they didn't already have it, but in keeping with the "don't hide that rustup/cargo/etc exist" motto, wasm-pack would not wrap the underlying rustup functionality or try to manage the rust toolchain versioning/install itself.

Basically, I think this npm package should be a small on-ramp to wasm-pack and that's it. All else, should we decide to implement it, should be implemented in wasm-pack itself.

Thoughts @robertohuertasm, @ashleygwilliams?

[robertohuertasm]

Just to make clear why I put all those things into the package, my inspiration was the windows-build-tools package. Whenever you try to write a native node module and you don't have all the underlying tooling installed (C++ build tools and Python) by just installing this package you get all that from a single source and you don't have to worry about knowing all the dependencies. Just focus on developing the native node module.

Being at work surrounded by other web developers I've found the easiest way to make them enter into the wasm world is by hiding a little bit the complexities of the dependencies. Whenever they feel they have to install Rust, install wasm-pack, change the toolchain (until this will change) and so on, they become overwhelmed. The same when you have to install the tooling to develop native node modules. Eventually I will learn that this is powered by Python, for instance, because the installer makes it pretty clear that the Python installation is taking place but I don't necessarily need to care about learning beforehand that I need it or where to get it and how to install it.

To be honest, I missed that wasm-pack was already adding the wasm32-u-u target. But to make my point clearer, I was thinking from the perspective of a web developer completely alienated from the Rust ecosystem. What if I told you that you don't have to care about installing Rust, wasm-pack, cargo-generate and so on. What if I told you, just use this tool that you know (npm) and use it to install all the dependencies that will allow you to start playing with a wasm project. Of course, later on, you will have to deal with Rust, and eventually learn the specifics about it, but you wouldn't have felt this process as a complicated thing. It was just introduced to you by a tool you know well. It's somehow like using a template to start a project. You just want a point where you can get all you need to start coding. I agree is somehow hiding it, but soon enough it will become clear what is really powering up all this. I think it more as a gradual/gentle introduction to the tooling.

My concerns about having just a wasm-pack installer in npm is that I don't see the point. Why should I need an npm installer if I already had to install Rust and have access to cargo? What would be the difference between doing npm i wasm-pack and cargo install wasm-pack? Indeed, I think having here the npm package will distract the users from cargo in an unnecessary way (but maybe I'm missing some point).

That being said, I completely understand other kind of motivations and I'll be happy to contribute as needed. 😃

[robertohuertasm]

Some of the ideas that were discussed today in the online meeting (all open to discussion):

1. wasm-pack installer should install Rust in case it's not already installed.
2. The npm package should only install wasm-pack.
3. Some were wondering if having several installers would lead to user's confusion vs user alternatives.

So basically the major alternatives are:

1. No npm package, as the wasm-pack installer will manage to install all that's needed.
2. The npm package will be another way to execute the wasm-pack installers (by executing the bash or powershell scripts).
3. In case wasm-pack doesn't install all the dependencies, extend the domain of the npm installer (that's the current approach).

▶️ From my point of view, strategy 2 has a really low cost in terms of implementation and maintenance as it will be using/downloading the new wasm-pack installer scripts (thus avoiding to keep two separate installation code scripts) and at the same time it will provide more exposure of wasm-pack to all kind of web developers that may find it more convenient to use npm instead of a raw usage of curl or powershell.

[drager]

@fitzgen @ashleygwilliams What will be the approach here? What should the npm package actually do?

[EverlastingBugstopper]

I think what we want to do here is to install wasm-pack as a pre-built binary. Installs will be much faster, and there will be no dependencies on Rust tooling.