-
Notifications
You must be signed in to change notification settings - Fork 409
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
should we -f wasm-bindgen install? #115
Comments
I wanted to see if there was a way to see if we can see a discrepency in versions somehow there is: michael@eva-01 ~ % cargo install wasm-bindgen-cli
Updating registry `https://github.com/rust-lang/crates.io-index`
Downloading wasm-bindgen-cli v0.2.6
Installing wasm-bindgen-cli v0.2.6
error: binary `wasm-bindgen` already exists in destination as part of `wasm-bindgen-cli v0.2.4`
binary `wasm2es6js` already exists in destination as part of `wasm-bindgen-cli v0.2.4`
Add --force to overwrite Now the solution to "Should we add -f" will be to parse this output and compare semver, possibly with a crate of some sort. Not gonna lie this is ugly and something we'll need to invoke on every call but it's better than nothing. If we go forward with this we should tell the user they'll always need to use the latest version, possibly warning them in the process of doing so. |
FWIW I definitely feel like Cargo should have a feature for this. In the meantime I'd recommend keeping up to date with the latest wasm-bindgen version if possible, even just tonight the latest Rust nightly broke wasm-bindgen and I had to publish a fix. Hopefully soon everything will be stable and breakage will be a thing of the past! |
@alexcrichton Ashley and I were talking, probably going to write up an RFC for this so you can do something like |
Sounds great! |
A dedicated command would be nice, but wouldn't (It would probably have to be run as two commands, and errors from the first command ignored, but...) |
Nope doesn't work for CLI tools :( |
FWIW I have always found |
@mgattozzi Ah, that's a real shame. I guess it'll require changes to cargo then. |
I feel like the developer experience will be much improved if I can lock wasm-pack and wasm-bindgen to a specific known-working version. Updates break things, and I'm not sure that simply having wasm-bindgen installed at all is something I really need help with from wasm-pack. I'm able to lock everything else in my development environment (including rust nightly). It's too bad cargo (AFAIK) can't install binaries per-project like npm does. |
Could wasm-bindgen export a library and then wasm-pack could use that instead? Then it’d be easier to lock, and no install needed. |
FWIW there's a |
This issue was brought up in #81, so I figured I'd pop in to say if there's anything that I can do to help with the cleaning up the |
So I was discussing this with @ashleygwilliams and it looks like the |
pros:
cons:
my desired behavior here would be similar to using the npm install @latest tag, which checks if the current installed version is the same as the version tag latest, if not installs, if so does nothing. i don't think cargo has this yet but perhaps i should write an rfc for it. i imagine we could write some logic to do this ourselves as well.
The text was updated successfully, but these errors were encountered: