You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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" ]
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.
The text was updated successfully, but these errors were encountered:
Got a quite specific issue here that arises when these conditions are filled:
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 betweennpm run build
andcargo 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.
The text was updated successfully, but these errors were encountered: