wasm-pack-plugin icon indicating copy to clipboard operation
wasm-pack-plugin copied to clipboard

Unnecessary recompiles when providing a .cargo/config file

Open therocode opened this issue 5 years ago • 1 comments

Got a quite specific issue here that arises when these conditions are filled:

  • A .cargo/config file is present to pass extra flags to the compiler
  • webpack.config.js sets mode to 'development'

Problematic behaviour observed:

Building the project through WasmPackPlugin (such as with npm run build) and then invoking cargo-check (such as when saving in VS-code, or simply just running cargo check in the commandline) will cause a full rebuild of all dependencies/files even if nothing changed.

Detailed behaviour:

Each of cargo-check or WasmPackPlugin can be invoked any number of times on their own and NOT trigger the full recompilation, however as soon as you invoke the other one it will cause the full rebuild once and then you can invoke that one instead any number of times until the first one is invoked again which will trigger full rebuild. Example:

Invoke cargo-check: full rebuild Invoke cargo-check: nothing Invoke cargo-check: nothing Invoke WasmPackPlugin build: full rebuild Invoke WasmPackPlugin build: nothing Invoke cargo-check: full rebuild Invoke WasmPackPlugin build: full rebuild ...

And yeah, this only happens if mode: 'development' and .cargo/config with a compiler flag is present.

My take on what happens: I'm pretty sure it is somehow triggered by the fact that if mode is 'development' then WasmPackPlugin will compile in Debug, which is also what cargo-check uses so they will then share the same folders under target/ I suppose? However, this doesn't explain why it only happens when a custom compiler flag is present, as this flag should be passed to cargo-check as well.

This is what I have in my .cargo/config: [target.'cfg(all())'] rustflags = [ "--cfg=web_sys_unstable_apis" ]

Here is a repo that reproduces the issue: https://github.com/therocode/wasm_pack_recompiles

You can see it by first doing npm install and then alternating between npm run build and cargo check.

I am currently working around this by setting mode to 'production' but such a workaround is not ideal. Any other workarounds/solutions would be appreciated, in the case that this is somehow not a bug.

therocode avatar Jan 15 '21 05:01 therocode

In your .cargo/config file try adding a target:

[build]
rustflags = ["--cfg=web_sys_unstable_apis"] 
target = "wasm32-unknown-unknown"

This has worked for me.

halzy avatar Jul 01 '21 03:07 halzy