koute / cargo-web Goto Github PK

I followed the steps here and it worked with the hello.rs to hello.js with rustc --target asmjs-unknown-emscripten hello.rs but now I'm trying to build a yew example and it says emscripten is not installed, why?

D:\3rdparty\yew\examples\counter>"d:\Program Files\emsdk-portable-64bit\emsdk_env.bat"
Adding directories to PATH:
PATH += d:\Program Files\emsdk-portable-64bit

Setting environment variables:
EMSDK = d:/Program Files/emsdk-portable-64bit
EM_CONFIG = C:\Users\me\.emscripten


D:\3rdparty\yew\examples\counter>cargo web start
error: you don't have Emscripten installed!

Download and install emscripten from the official site: http://kripken.github.io/emscripten-site/docs/getting_started/downloads.html

(I have to use asmjs instead of wasm to support old browsers.)

EDIT: The hello.rs example worked in the emscripten sdk folder, but when I copy the hello.rs file to another folder and start a cmd.exe there and then run rustc --target asmjs-unknown-emscripten hello.rs I get note: 'emcc.bat' is not recognized as an internal or external command, operable program or batch file. even though I ran emsdk_env.bat in that shell, why?

This will probably get easier once Webpack or some other tool is better integrated, but right now I'm manually building a static PWA page for loading my assets. One minor gotcha is that, in development mode, the loader is served up as /js/app.js, while the release build seems to create files named my_crate.{js,wasm}.

I understand that this is fairly easy to mitigate by moving some files, but I wonder if a better solution might be serving up the files at /my_crate.{js,wasm} in development mode too? Then I could use the regular static assets unmodified between development and production if I like, simply copying src/static into the target directory and publishing that to my server.

I'm willing to try taking this on, I just want to know if there's some gotcha related to serving up assets based on their target name rather than the generic /js/app.js. Thanks.

Right now if I push to /page and reload it will 404. If the behaviour to opt in to history api fallback (as is implemented for webpack-dev-server) with a flag could be implemented, that would be awesome!

Looking at the code now it just tries to match / or /index.html. I think this could be moved to the last match if the flag was present, to try and pick off the other routes first.

generate multiple js files. each html files can han one or other js file. Currently supported?
another Currently supported SPA?

Hi on trying to run cargo install cargo-web on macos I get the following error:

Compiling app_dirs v1.1.1
error[E0619]: the type of this value must be known in this context
--> /Users/rebo/.cargo/registry/src/github.com-1ecc6299db9ec823/app_dirs-1.1.1/src/imp/platform/macos.rs:10:40
|
10 | Ok(Component::RootDir.as_ref().into())
| ^^^^

error: aborting due to previous error

Any ideas?

Basically see title. I'm using Arch Linux and have emscripten and binaryen installed and working using provided packages but cargo-web still tries to download these. Can't it use system packages?

Technically this has its root cause in another crate, but may require upgrading another package version to get the fix.

I get

error[E0583]: file not found for module `montgomery`

in ring v0.11.0 when trying to install with rustup override set to nightly for the directory. It looks like this is fixed at least in ring 0.13.0:
briansmith/ring#598

If I install with stable, it runs fine.

With the latest release of cargo-web, the output on PowerShell looks like this:

I don't remember this being an issue with the 0.4.x series, but I can't remember if I actually tested the 0.4.x series on my Windows computer, or if I had merely installed it here. I know I had played with cargo web on my Linux laptop. Either way, the colors seem to be broken now.

As we can see in travis log, cargo install cargo-web takes about 10 minutes. It can be much faster if we will just download a compiled binary. It is done by "just" utility, for example.

As far as I can tell this is not done currently, but it should be simple to integrate.

Is this on the roadmap at all?

Hi, I can't get static files to be served, no matter what path I try, is there anything that isn't in documentation I should be aware of to get it working?

I'd love to see a command or arg that allowed building the app into a deployable package. Today I use this build script. Something like cargo-web package or maybe just cargo-web build -d <outdir> --release.

I'd like to use my own custom index.html when starting the cargo web server.

If I start a server using cargo web start it correctly builds the package and launches a server with a working page. But if I change anything and a rebuild is triggered it errors with:

error: could not exec the linker `emcc`: No such file or directory (os error 2)
  |
  = note: "emcc" "-s" "DISABLE_EXCEPTION_CATCHING=0" "-L" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/catalyst-ad556bdccbf1bed8.0.o" "-o" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/catalyst-ad556bdccbf1bed8.js" "-s" "EXPORTED_FUNCTIONS=[\"_main\",\"___rdl_shrink_in_place\",\"___rdl_alloc_excess\",\"___rdl_usable_size\",\"___rdl_alloc\",\"___rdl_realloc_excess\",\"___rdl_realloc\",\"___rdl_oom\",\"___rdl_grow_in_place\",\"___rdl_alloc_zeroed\",\"___rdl_dealloc\",\"_rust_eh_personality\"]" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/catalyst-ad556bdccbf1bed8.crate.allocator.o" "-O0" "--memory-init-file" "0" "-g4" "-s" "DEFAULT_LIBRARY_FUNCS_TO_INCLUDE=[]" "-L" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps" "-L" "/home/rasmus/Development/catalyst/target/debug/deps" "-L" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/libcatalyst-b47ad62f78790a7a.rlib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/libstdweb-7bfa732ce4e281cb.rlib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/libserde_json-2e6a65e2f75759e0.rlib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/libdtoa-49eaf858ed5bb53b.rlib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/libitoa-9afcb23e92bf9413.rlib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/libserde-c29e90fe3a0f30b7.rlib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/libnum_traits-379830a7c273381b.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/libstd-881b9fdbdf1d515b.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/liballoc_system-3c10208cdd7e61cb.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/librand-32f648f7f7567c6c.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/libpanic_unwind-9cbadc6554202be9.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/libunwind-618c266cf9124966.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/liblibc-16f3b02b9a976b94.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/liballoc-bc70b4efeaeb398c.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/libstd_unicode-a0ad42dc8f5856aa.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/libcore-21491ce3d14f1ef2.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/libcompiler_builtins-b9713bd7f605c0b2.rlib" "-l" "c" "-s" "ERROR_ON_UNDEFINED_SYMBOLS=1"

error: aborting due to previous error

Is there some path magic that is applied the first build but not for the rest of the builds?

^ Title

I just started with cargo web and I noticed that if I run commands multiple times (e.g. cargo web test) that because artifacts in target/ have not changed cargo-web panics:

$ cargo web test --nodejs --target-webasm
warning: debug builds on the wasm-unknown-unknown are currently totally broken
         forcing a release build
    Finished release [optimized] target(s) in 0.0 secs
thread 'main' panicked at 'internal error: nothing changed so I don't know which artifact corresponds to this build', /Users/stephen/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-web-0.4.0/src/main.rs:830:16
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Working around this issue is easy enough, as it turns out: I just needed to modify my code in some way before running the command again. But the error message here was not obvious to me initially, and so it had me searching online for solutions without finding anything.

When compiling my Rust application with --target-asmjs-emscripten I ran into some situations where there are APIs which are simply not supported in JS (such as threads), which then causes a runtime panic.

I would like to be able to compile my application for use on either the desktop (with full support) or JS / Wasm (without support for things like threads) and conditional compilation seems like a good way to accomplish that.

However, I wasn't able to find a way to do that. The --features flag doesn't work, and I couldn't find whether cargo-web sets a special config flag when compiling. Is conditional compilation supported, or planned to be supported?

P.S. I'm a JavaScript expert, learning Rust, and I would really like to be able to use Rust on the web, so I'm interested in helping out with pull requests.

Hi, thanks for implementing the new deploy command! :) On a new project, I ran cargo web deploy... to get a fresh template. I then edited it, added links to CDN-hosted stylesheets, and placed it in src/static.

It's surprising to me that the deploy command doesn't respect src/stattic. Running it again gives me a fresh template in target/deploy.

In cases where src/static exists, I'd expect cargo web deploy to copy over index.html, as well as any other files contained therein, and only overwrite index.html if it is missing.

Thanks!

I tried compiling my Rust application with --target-webasm-emscripten but when I ran it, I got this runtime error:

Cannot enlarge memory arrays. Either (1) compile with  -s TOTAL_MEMORY=X  with X higher
than the current value 16777216, (2) compile with  -s ALLOW_MEMORY_GROWTH=1  which allows
increasing the size at runtime but prevents some optimizations, (3) set Module.TOTAL_MEMORY
to a higher value before the program runs, or (4) if you want malloc to return NULL (0)
instead of this abort, compile with  -s ABORTING_MALLOC=0 

According to the Emscripten docs, you can use ALLOW_MEMORY_GROWTH to fix this.

I recommend adding -s ALLOW_MEMORY_GROWTH=1 by default to the emcc command, since it has little to no downside on WebAssembly.

It would be helpful to add a subcommand that generates default static content at the correct path. I'd like to modify the default HTML, but am not immediately sure what it should look like. I suppose I could wget the result of cargo web start, but I don't know what parts of that are needed in the static directory and what aren't.

Further, I thought cargo web build would output everything I'd need to host a wasm app on a static site, but I can't find any HTML to post. Maybe I'm fundamentally misunderstanding something about how to host an app?

Thanks.

I get this:

RUST_BACKTRACE=1 cargo web start --target-webasm-emscripten --use-system-emscripten
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 2, message: "No such file or directory" } }', /checkout/src/libcore/result.rs:916:4
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at /checkout/src/libstd/sys_common/backtrace.rs:68
             at /checkout/src/libstd/sys_common/backtrace.rs:57
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:498
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:71
   9: core::result::unwrap_failed
  10: cargo_web::command_start
  11: cargo_web::main
  12: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:101
  13: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:459
             at /checkout/src/libstd/rt.rs:58
  14: __libc_start_main
  15: _start

but cargo web start --target-asmjs-emscripten --use-system-emscripten works just fine. My system has emscripten 1.37.25 and binaryen 40 installed.

On top of fixing this error, I'd like to note that you should probably rather use an expect there instead of an unwrap so that people know what's wrong exactly.

I'm interested in packaging this application. To do that I would need you to create tags when releasing a new version. This causes github to create a .tar.gz for those tags that I can use to build the package. :)

Currently, using some math functions e.g. (1.0 as f64).sin() with wasm results in a runtime error.

I'm not sure whose "fault" it is, nor where the best place to solve it is; but, one way is to provide these functions in the import section when instantiating the wasm module.

env: {
  // ...
  "sin": Math.sin
  "cos": Math.cos
  // ...
}

I'm not that familiar with wasm-JS interop, so this could be horribly inefficient. But, is slow worse than broken?

I have a project with workspace, one of the workspace member is using cargo-web.
Outside the workspace it works fine, but if it's inside workspace member it's panicking. Both asmjs and wasm32 is panicking.

[workspace]
members = [
  "server/",
  "client/"
]

RUST_BACKTRACE=1 cargo web start --target wasm32-unknown-emscripten
thread 'main' panicked at 'Unknown target kind: 'dylib'', src/cargo_shim/mod.rs:236:38
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:380
   3: std::panicking::default_hook
             at libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:576
   5: std::panicking::begin_panic
             at libstd/panicking.rs:537
   6: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:521
   7: <core::iter::FilterMap<I, F> as core::iter::iterator::Iterator>::next
   8: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
   9: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &'a mut F>::call_once
  10: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
  11: cargo_web::cargo_shim::CargoProject::new
  12: cargo_web::build::BuildArgs::load_project
  13: cargo_web::cmd_start::command_start
  14: cargo_web::main
  15: std::rt::lang_start::{{closure}}
  16: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:479
  17: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  18: std::rt::lang_start_internal
             at libstd/panicking.rs:458
             at libstd/panic.rs:358
             at libstd/rt.rs:58
  19: main
  20: __libc_start_main
  21: _start

chrome.exe --version does not print out version information on windows, it just launches a new window. You can use which/where to check whether a command exists without running it - there's an implementation in rustup you can steal.

Seems like this used to work, but it no longer does, and the -v option doesn't provide any clarity. Running the V0.6.0 release under Linux.

Thanks!

Currently, it is not possible to integrate stdweb/cargo-web crates into a webpack-based project without a few modifications.

I came across the following hiccups in the process:

1. Since Webpack uses NodeJS the wasm_runtime.js goes into the wrong branch and attempts to load NodeJS modules during the webpack build process which fails because webpack replaces the calls to require (indirectly) with the required module which fails and shouldn't have happened in the first place.

2. The path to the wasm file is currently hardcoded to the webroot but it may be desirable to either:
   a. Use a configurable path which may or may not be the webroot.
   b. Use a webpack file-loader to bundle the wasm code at build time by using the wasm-loader possibly in combination with the rust-native-wasm-loader.
   Note: Attempt documented two comments below.

3. When server-side rendering is used the wasm modules won't load on the server when 2.a is used and the wasm_runtime.js is included in the webpack bundle. It fails with the following error message:

Error loading Rust wasm module 'rtvcs_web': Error: only absolute URLs are supported

Additionally, it would be nice to have a webpack-loader that somehow integrates cargo-web into a webpack project.

Note: This all corresponds to the wasm32-unknown-unknown target.

This is something I'm not sure where the problem lies in as I found it via testing yew but it appears that while a source map is generated, neither Chrome or Firefox can find it. Maybe this isn't a problem with cargo-web and might be a misconfiguration of yew. I'm building with the emscripten target and not the built-in WASM from Nightly currently (using stable Rust from Rustup)

Hey @koute , is it possible to make cargo web deploy to output to target-dir ?
https://doc.rust-lang.org/cargo/reference/config.html

I've configured cargo target-dir but it always output to current cargo dir. Or is it possible to specify output dir like cargo web deploy --output /some/dir ?

When using cargo web in a script or from a different tool it would be great to get log output as line separated JSON objects so that they can be parsed into meaningful data to be displayed to the user.

Normal cargo already supports this so I guess it's only a question of passing through a flag and maybe logging additional things from this tool (such as the location of generated js files)

I want to add support for richer error handling in https://github.com/dflemstr/rust-native-wasm-loader and lacking support for this makes things harder than necessary.

I have Windows7 64-bit. I fired this command cargo install cargo-web. I am using rustc 1.23.0.
I am getting an error -

error: linking with link.exe failed: exit code: 1181 | = note: "C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\VC\\bin\\amd64\\link.exe" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\ \Users\\VISHAL\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Users\\VISH AL\\AppData\\Local\\Temp\\cargo-install.VN2UTPu1F7E5\\release\\deps\\cargo_web-fdfc46013556d8f2.cargo_web0.rcgu.o......

= note: LINK : warning LNK4044: unrecognized option '/NATVIS:C:\Users\VISHAL\.rustup\toolchains\stable-x86_64-pc-windows-msvc \lib\rustlib\etc\liballoc.natvis'; ignored LINK : warning LNK4044: unrecognized option '/NATVIS:C:\Users\VISHAL\.rustup\toolchains\stable-x86_64-pc-windows-msvc \lib\rustlib\etc\libcore.natvis'; ignored LINK : fatal error LNK1181: cannot open input file 'synchronization.lib' error: aborting due to previous error error: failed to compile cargo-web v0.5.2, intermediate artifacts can be found at

I'd like to download Emscripten, then run commands in the downloaded installation to install ports. This is for a CI environment generating automated builds.

I don't see a way to do this other than triggering a build, which will fail since the environment lacks the necessary tools, then using the freshly-installed Emscripten to set up the environment for a second build that succeeds. A download command would help with that. Or maybe an emscripten command so other subcommands might be added in the future. I don't care much about what the command is called, as long as I can just download whatever Emscripten version cargo-web supports so I can install ports before building. :)

Thanks.

Seemingly it is not possible to run cargo web build --features="someFeature".
Would be nice to have!

I tried splitting a project into a cargo workspace, and found an odd issue. I separated my project into a local library crate that the main project depends on.

[package]
# ...

[workspace]
members = ["./local-lib"]

[dependencies]
local-lib = { path = "./local-lib" }
stdweb = "*"

after doing this, "cargo web start" throws the following error

$ cargo web start
error: cannot start a webserver for a crate which is a library!

I fixed it by removing the workspace section in the toml

[package]
# ...

[dependencies]
local-lib = { path = "./local-lib" }
stdweb = "*"

It seems like it thinks that the main project is a different type of crate when the workspace tag is set, but I think this is a perfectly valid setup for a workspace. is there any reason why cargo-web rejects this?

The command cargo install cargo-web,
after a minute and half of compiling, printed:

error: failed to run custom build command for `openssl-sys v0.9.24`
process didn't exit successfully: `/tmp/cargo-install.aKdf8gWcEAu5/release/build/openssl-sys-5ee2bfe045b42a7a/build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_LIB_DIR
cargo:rerun-if-env-changed=OPENSSL_LIB_DIR
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_INCLUDE_DIR
cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_DIR
cargo:rerun-if-env-changed=OPENSSL_DIR
run pkg_config fail: "`\"pkg-config\" \"--libs\" \"--cflags\" \"openssl\"` did not exit successfully: exit code: 1\n--- stderr\nPackage openssl was not found in the pkg-config search path.\nPerhaps you should add the directory containing `openssl.pc\'\nto the PKG_CONFIG_PATH environment variable\nNo package \'openssl\' found\n"

--- stderr
thread 'main' panicked at '

Could not find directory of OpenSSL installation, and this `-sys` crate cannot
proceed without this knowledge. If OpenSSL is installed and this crate had
trouble finding it,  you can set the `OPENSSL_DIR` environment variable for the
compilation process.

If you're in a situation where you think the directory *should* be found
automatically, please open a bug at https://github.com/sfackler/rust-openssl
and include information about your system as well as this message.

    $HOST = x86_64-unknown-linux-gnu
    $TARGET = x86_64-unknown-linux-gnu
    openssl-sys = 0.9.24

The command which openssl prints /usr/bin/openssl, and so I tried also the command OPENSSL_DIR=/usr/bin cargo install cargo-web, getting the following output:

error: failed to run custom build command for `openssl-sys v0.9.24`
process didn't exit successfully: `/tmp/cargo-install.FbQ5fWKqfqMJ/release/build/openssl-sys-5ee2bfe045b42a7a/build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_LIB_DIR
cargo:rerun-if-env-changed=OPENSSL_LIB_DIR
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_INCLUDE_DIR
cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_DIR
cargo:rerun-if-env-changed=OPENSSL_DIR

--- stderr
thread 'main' panicked at 'OpenSSL library directory does not exist: /usr/bin/lib ...

I'm porting a single page app from polymer to yew and I had a gulp task that uses browser-sync to auto reload but also proxy request to "/api" to the real backend server, how can I do that with cargo web?

If it doesn't support proxy, how can I tell cargo web to only build on source change (so that I can use browser-sync to watch the build output and use that for proxying, like I do with PureScript)?

When using this tool combined with common web infrastructure such as webpack, it's useful to be able to control how the wasm file is loaded from Javascript instead of hardcoding a fetch call.

It might be useful to use the native wasm support in Webpack 4 for example, where the exports from a wasm file can be imported simply using import {myfunction} from "bla.wasm";

We might also want to put the wasm file on a CDN or integrate it with a service worker asset loader etc. which also requires being able to customize the wasm file url.

Right now I do this by search replacing the generated url like so: https://github.com/dflemstr/rust-native-wasm-loader/blob/f30905197637b7e3dbccfdd1ac61a43709d395d5/index.js#L68

Being able to configure emscripten ports would be nice, possibly with features
Otherwise the user needs to go an manually run
embuilder.py build all and set EMMAKEN_CFLAGS

Right now if you use cargo web start it will automatically re-build if the files change, which is great!

But I'm developing a Chrome Extension, so cargo web start doesn't work for me (because the compiled files are loaded into the browser, not displayed on an HTML page).

So it would be great if I could do cargo web build --watch, cargo web deploy --watch, and cargo web test --watch

When using the --watch option it will watch for file changes (just like cargo web start) and will then re-run cargo web build (or cargo web deploy / cargo web test) automatically.

My Cargo.toml contains these lines:

[target.'cfg(target_arch = "wasm32")'.dependencies]
stdweb = "0.3"

[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
glutin = "*"

But when i use cargo web build --target-webasm to build, it still be referenced glutin.
Did i do something wrong ? Or how can switch between normal arch and wasm32 one ?

Do you think a cargo web node makes sense to launch the .js file with node?

I'd love to see support for https://www.hellorust.com/news/native-wasm-target.html in cargo-web; I think it's going to be an even bigger target than the emscripten one.

Right now if you launch cargo web test it will launch your tests in a new Chrome/Chromium instance it finds installed on your system. This is a huge hack which should be replaced by a proper headless browser (either headless Chromium or headless Firefox, or even both, because cross browser testing is important).

• Write a driver for one of the headless browsers in Rust. (This shouldn't have any external dependencies like Node.js, etc.)
• Replace the current cruddy way of running tests.
• Set up an automated way to build a package with our headless browser just as we're currently building Emscripten and Binaryen under Docker. (Linux only for now.)
• Make cargo-web automatically download and install it.

I'm hacking on this code. If I run:

cargo web build --target-webasm-emscripten

The project builds fine. If I run:

cargo web build --target-webasm-emscripten --release

the build fails with screens of errors, at the top of which is:

  = note: WARNING:root:emcc: cannot find library "SDL2"

The errors look like so:

          WARNING:root:object /tmp/emscripten_temp_3wyyWe_archive_contents/ncollide-cfdd2aa6ffc25dc6.ncollide0.rust-cgu.bytecode.encoded is not valid, cannot link

This is with a stock Emscripten environment under Linux (I.e. the prebuilt 1.37.27 binaries.) No other change is made in the environment beyond adding --release to the build command, and I'm using latest Rust stable.

So I know I can use Web.toml to define link-args = ["-s", "ASYNCIFY=1"] but that's not the issue here. I get this with either link-args = ["-s", "ASYNCIFY=1"] in Web.toml or EMMAKEN_CFLAGS="-s ASYNCIFY=1" cargo web build --target-wasm-emscripten --use-system-emscripten --release:
log.txt

Without that line or env var it works fine. However! EMMAKEN_CFLAGS="-s ASYNCIFY=1" cargo build --target wasm32-unknown-emscripten --release works just fine and has the desired effect. What's up here?

Oh... guys, half of humanity really needs this tool, but it is totally ungooglable! I've just reinvented the wheel to solve the same problem, but then found your excellent solution.

And yes, "stdweb" have the same problem, I assure you.

Auto reload would be handy for my kind of development.

Cargo-web could provide a websocket which pushes a notification when a newly compiled result is available. (Automagically injected?) Browser Side JS would listen and decide whether to reload or not. It would be enabled via a command line flag, e.g. --recompile-status.