Mass rename anyref to externref

[alexcrichton]

Updates a mess of dependencies and tracks the most recent version of the
reference types specification.

[zancas]

Hi @alexcrichton ! It seems like this change may have broken our build (though I don't know how a variable name change could have).

Our project provides the following build error when we try to build against the latest wasm-bindgen:

+ TARGET=target/wasm32-unknown-unknown/debug
+ cargo build --features=fail-on-warnings --target wasm32-unknown-unknown
   Compiling wasm-bindgen-shared v0.2.62 (https://github.com/rustwasm/wasm-bindgen.git#3dd8f3d2)
   Compiling wasm-bindgen v0.2.62 (https://github.com/rustwasm/wasm-bindgen.git#3dd8f3d2)
   Compiling zcash_client_backend v0.2.0 (https://github.com/zcash/librustzcash.git#5ff85627)
   Compiling wasm-bindgen-backend v0.2.62 (https://github.com/rustwasm/wasm-bindgen.git#3dd8f3d2)
   Compiling wasm-bindgen-macro-support v0.2.62 (https://github.com/rustwasm/wasm-bindgen.git#3dd8f3d2)
   Compiling wasm-bindgen-macro v0.2.62 (https://github.com/rustwasm/wasm-bindgen.git#3dd8f3d2)
   Compiling js-sys v0.3.39 (https://github.com/rustwasm/wasm-bindgen.git#3dd8f3d2)
   Compiling console_error_panic_hook v0.1.6
   Compiling wasm-bindgen-futures v0.4.12
   Compiling web-sys v0.3.39
   Compiling web-extension v0.1.0 (https://gitlab.com/ZingO-Labs/tab-organizer.git?branch=rust#9a3e3924)
   Compiling wasm-bindgen-test v0.3.12
   Compiling zingo_webextension v0.0.1 (/home/pherder/ZingOLabs/webextension)
    Finished dev [unoptimized + debuginfo] target(s) in 34.74s
+ rm -rf wasms
+ wasm-bindgen --out-name bindgens.wasm --out-dir ./wasms --target no-modules target/wasm32-unknown-unknown/debug/zingo_webextension.wasm
error: cannot import from modules (`__wbindgen_externref_xform__`) with `--no-modules`

Since our WASM is running in a webextension we don't have a straight-forward way to support ES6 modules.

Any feedback, much appreciated!

[Pauan]

@zancas I've written several WebExtensions with Rust, and ES6 modules with --target web do work:

• In background/popup scripts you can just use <script type="module" src="path/to/foo.js"></script>

• In content scripts you can create a tiny .js wrapper file which imports the ES6 module:

  import("./path/to/foo.js").catch(console.error);

  You also need to make the files accessible to the content script.

I recommend using our Rollup plugin since it is fast, lightweight, easy to setup, supports multiple crates, supports watch mode, can automatically bundle your extension as a .zip, etc.

[alexcrichton]

I'd second what @Pauan says, it looks like @zancas you're manually running Cargo and wasm-bindgen, and the error here is probably a mismatch of the wasm-bindgen CLI version and crate version you're linking in.

[AloeareV]

https://bugzilla.mozilla.org/show_bug.cgi?id=1536094 According to this, there's a firefox-specific bug where content scripts are incapable of importing EC6 modules.

Our wasm-bindgen --version and the wasm bindgen version = in the Cargo.lock are both 0.2.62, so that's not likely the issue

[AloeareV]

If y'all can't replicate the --target no-modules error, then there's something weird going on in our local state we need to debug, but --target web solution as far as I can tell doesn't work in Firefox.

[Pauan]

@AloeareV In that case you can use Rollup with iife output, or Webpack. That will compile it into regular ES5 code. If you're doing that, then you don't need the dynamic import() anymore.

If you don't want to use Webpack or Rollup, you should be using wasm-pack. It isn't really intended to run wasm-bindgen manually.

I can successfully use --target no-modules with the latest version of wasm-bindgen, so it must be a problem with your setup (which is probably fixed by using Webpack, Rollup, or wasm-pack).