--skip-build flag #144
Comments
ashleygwilliams
added
help wanted
|
One important thing to note is that the order of what happens has a specific number of steps hardcoded in the output. We'll need to add checks to choose the right amount if this flag is added. i.e. instead of say step [3/7] with this flag we might just need to do [2/3] |
|
@mgattozzi good call. i mean, this is probably a good reason to stop hardcoding that stuff in the first place. the more steps and flags we add the more likely we'll want to have a dynamic way to set up a list of steps we want and then count them from there. |
|
@ashleygwilliams I'm thinking maybe an enum of some sort that can be matched against to choose the right number. This kind of brings us to the context type in #123. I think the app and the granularity we need is too big to pass in individual arguments anymore. But yeah this should be more dynamic not hardcoded |
ashleygwilliams
added
PR attached
|
First apologies. Just noticed this issue. I'm aware there's already a pull request. This flag simultaneously does something I really want and also has qualities that make it less useful. Parts of this flag that I really like: "Adding the target" and "installing wasm-bindgen" affect the user's global environment. That always has a lot of potential to cause surprise or breakage. Especially if I give anyone (coworker or stranger on github) a build script that uses wasm-pack as an intermediate step I have to be very careful to educate them about what is going to happen (and some people would interpret an indirectly-commanded software install as malware, eep!). Also these steps are slow. So suppressing these is a big win except when they're wanted. Parts of this flag that feel regrettable: Having disabled the above, I still want "Compiling to wasm" and "running wasm-bindgen". And these are relatively fast operations. In --debug mode, we get incremental compilation, and even in release mode there seems to at least be some kind of short-circuit behavior. So, AFAICS, if someone is saving time by skipping these steps, then that itself is evidence that their output is stale and probably wrong and not what they intend. I put some times below; emphasis on the very last result, which is sub-second despite apparently rebuilding a 1.4M wasm file. I actually re-run wasm-pack in some cases 10-20 times in an hour if I'm fine-tuning something, so I'm intensely interested in these times. I hope this is helpful. (Note to avoid confusing anyone who comes across this ticket: as of this writing, the --debug flag lives in a pull request and is not yet a part of wasm-pack.) At this point, I rebuild wasm-pack to never run rustup or cargo install wasm-bindgen: |
|
hey @clanehin i think that this is incredibly useful and different "build profiles", or sets of wasm-pack steps, is something that i am also doing a lot of thinking about right now. the fact that wasm-pack currently affects the global env is something i'm not pleased about and is something we are actively discussing mitigating in #146 (at least for the so one question for you- do you have a suggestion about improving the current PR? or do you think perhaps what you are suggestion is another mostly- i think what you're saying here is very valuable but i'm not sure, and am curious, exactly what your ask is! |
I guess I left it out in the spirit of, "let me show you my data and see if you come to same conclusion I did." So, I hope I've convinced you that we don't need to skip building the output (wasm and package.json and support javascript). I also see two disadvantages: as a pedagogical tool, it risks creating extra novelty for the learner to keep track of, and as an everyday-use tool it risks leaving the user with stale output. So we could rename --skip-build to --no-installs, and just not disable the build (but do disable touching the environment) and call it done. That isn't very much work over the existing PR and gives us what we need. I've also thought about a couple of other ways to bikeshed this, like having a separate command Alternately, we could have a readline interface " |
|
@clanehin so- i think all of this is really great and i think i would like to open up a new issue to get a mostly, i think i would like to merge the |
|
ok- i am going to make a sort of executive call to merge the current PR- but please don't view this as me dismissing or diminishing your comments. i think if we need to we can still deprecate and/or change --skip-build. i'd like to get this refactor in now to unblock a bunch of PRs. i'll start up a new issue to discuss this stuff :) |
Add --skip-build flag for init command #144
|
closed by #151 |
I noticed. Entirely sensible; if anyone still feels they would benefit from --skip-build I don't see any reason to deprive them of it. |
while teaching wasm-pack, i discovered that sometimes we want to run wasm-pack init again (updated readme or cargo.toml) but don't want to rebuild the whole pkg
let's add a
--skip-buildflag that will skip:it should warn if the wasm file does not exist in target (was not yet compiled) or if the bg.wasm or js module wrapper are not present (hasnt yet run wasm-bingden)
The text was updated successfully, but these errors were encountered: