Repository navigation
Replace wasm-pack #1836
Description
Activity
- addedgood first issueTasks suited for learning the compiler codebaseTasks suited for learning the compiler codebase
on Feb 14, 2023 - added 2 commits that reference this issue
on Feb 19, 2023 There's now a library that will do build a wasm package as part of the build:
Quoting from #2158
https://crates.io/crates/substrate-wasm-builder
It requires nightly, which we won't ever require, but also possibly it might be moving to not require nightly? paritytech/substrate#13580
We're 2-3 months behind on the toolchain, so assuming this works, we could use this in a few months to replace wasm-pack. That would simplify the build a lot as well as solving this perf issue.
So I'll mark this as postponed, but leave it open, and we can implement this when it's available. It'll make the builds faster, much much faster when there are no changes, and reduce our use of unsupported crates.
- added and removedgood first issueTasks suited for learning the compiler codebaseTasks suited for learning the compiler codebase
on Mar 23, 2023 - changed the title
[-]Replace `wasm-pack` with bare `wasm-bindgen`[/-][+]Replace `wasm-pack`[/+]on Mar 23, 2023 Update:
substrate-wasm-builderis cool but not that practical for us — it doesn't generate the JS file. It compiles a.wasmartifact by creating a whole new crate at build-time, building it, and then copying the.wasmartifact back 1- https://github.com/rustminded/xtask-wasm looks good as a replacement but doesn't seem to handle generating the
package.jsonetc, whichwasm-packdoes - More understanding in Building with `build.rs` wasm-bindgen/wasm-bindgen#3494 (reply in thread)
- So — stepping back — except from the general overhead of having
wasm-packaround, the main pain comes from runningwasm-opton each run — it has no caching, and so is run on every run.
So I think for the moment, we can have a build option that runs with
--dev, which skipswasm-opt, which we can run locally. And then we can return to this if the ecosystem's tooling improves.Footnotes
-
Given that it doesn't create JS files, I'm not sure why it does this, rather than just compiling the main project with wasm — possibly there are parts of the project that want to use a default target but which want to use a
.wasmbinary. ↩
- added 2 commits that reference this issue
on Jun 22, 2023
Not the most urgent item, but would be good to keep our build steps as uncomplicated as possible, and remove dependencies that aren't maintained.
Currently we use
wasm-packto bundleprql-js. IIUC we're using it becausewasm-packdoes wellwasm-bindgenalone, we keptwasm-packand addedpackage.jsonscripts to move the files it output (link above)For context,
wasm-packis a wrapper ofwasm-bindgenand isn't really maintained, whereaswasm-bindgenremains well-supported.As discussed in https://rustwasm.github.io/docs/wasm-bindgen/reference/deployment.html, I think it should be possible to remove this middle layer and use
wasm-bindgenalone; likely using a similar set of steps to what we do now inpackage.jsonscripts.This would be a good contribution for someone who's somewhat familiar with JS, and would like an early PR before diving into the PRQL compiler.