Relax schema version constraints (#2546)

CHANGELOG.md

@@ -915,8 +915,7 @@ Released 2019-04-10.
 
 ### Added
 
-* Initial support for transitive NPM dependencies has been added, although
-  support has not fully landed in `wasm-pack` yet so it's not 100% integrated.
+* Initial support for transitive NPM dependencies has been added.
   [#1305](https://github.com/rustwasm/wasm-bindgen/pull/1305)
 
 * The `constructor` property of `Object` is now bound in `js-sys`.

benchmarks/README.md

@@ -20,7 +20,8 @@ $ cp ./benchmarks /some/other/directory
 Next, `cd` into that directory and execute:
 
 ```
-$ wasm-pack build --target web
+$ cargo build --release --target wasm32-unknown-unknown
+$ wasm-bindgen --target web ./target/wasm32-unknown-unknown/release/crate.wasm
 ```
 
 Next, use your favorite static file server to host the current directory. For

crates/cli-support/src/wit/mod.rs

@@ -1457,15 +1457,16 @@ fn extract_programs<'a>(
                     "
 
 it looks like the Rust project used to create this wasm file was linked against
-a different version of wasm-bindgen than this binary:
+version of wasm-bindgen that uses a different bindgen format than this binary:
 
-  rust wasm file: {}
-     this binary: {}
+  rust wasm file schema version: {}
+     this binary schema version: {}
 
-Currently the bindgen format is unstable enough that these two version must
-exactly match, so it's required that these two version are kept in sync by
-either updating the wasm-bindgen dependency or this binary. You should be able
-to update the wasm-bindgen dependency with:
+Currently the bindgen format is unstable enough that these two schema versions
+must exactly match. You can accomplish this by either updating the wasm-bindgen
+dependency or this binary.
+
+You should be able to update the wasm-bindgen dependency with:
 
     cargo update -p wasm-bindgen
 

crates/shared/build.rs

@@ -1,6 +1,11 @@
+use std::collections::hash_map::DefaultHasher;
+use std::hash::Hasher;
+use std::path::PathBuf;
 use std::process::Command;
 
 fn main() {
+    set_schema_version_env_var();
+
     let rev = Command::new("git")
         .arg("rev-parse")
         .arg("HEAD")
@@ -14,3 +19,13 @@ fn main() {
         }
     }
 }
+
+fn set_schema_version_env_var() {
+    let schema_file = PathBuf::from(concat!(env!("CARGO_MANIFEST_DIR"), "/src/lib.rs"));
+    let schema_file = std::fs::read(schema_file).unwrap();
+
+    let mut hasher = DefaultHasher::new();
+    hasher.write(&schema_file);
+
+    println!("cargo:rustc-env=SCHEMA_FILE_HASH={}", hasher.finish());
+}

crates/shared/src/lib.rs

@@ -1,8 +1,12 @@
 #![doc(html_root_url = "https://docs.rs/wasm-bindgen-shared/0.2")]
 
-// The schema is so unstable right now we just force it to change whenever this
-// package's version changes, which happens on all publishes.
-pub const SCHEMA_VERSION: &str = env!("CARGO_PKG_VERSION");
+#[cfg(test)]
+mod schema_hash_approval;
+
+// This gets changed whenever our schema changes.
+// At this time versions of wasm-bindgen and wasm-bindgen-cli are required to have the exact same
+// SCHEMA_VERSION in order to work together.
+pub const SCHEMA_VERSION: &str = "0.2.74";
 
 #[macro_export]
 macro_rules! shared_api {

crates/shared/src/schema_hash_approval.rs

@@ -0,0 +1,16 @@
+// Whenever the lib.rs changes, the SCHEMA_FILE_HASH environment variable will change and the
+// schema_version test below will fail.
+// Proceed as follows:
+//
+// If the schema in this library has changed then:
+//  1. Change this APPROVED_SCHEMA_FILE_HASH to the new hash.
+//
+// If the schema in this library has changed then:
+//  1. Bump the version in `crates/shared/Cargo.toml`
+//  2. Change the `SCHEMA_VERSION` in this library to this new Cargo.toml version
+const APPROVED_SCHEMA_FILE_HASH: &'static str = "12458387802132375736";
+
+#[test]
+fn schema_version() {
+    assert_eq!(env!("SCHEMA_FILE_HASH"), APPROVED_SCHEMA_FILE_HASH)
+}

guide/src/reference/cli.md

@@ -4,34 +4,11 @@ The `wasm-bindgen` command line tool has a number of options available to it to
 tweak the JavaScript that is generated. The most up-to-date set of flags can
 always be listed via `wasm-bindgen --help`.
 
-> Note: usually, one should use a [`wasm-pack`-based workflow][wasm-pack] rather
-> than running the `wasm-bindgen` command line tool by hand.
-
-[wasm-pack]: https://github.com/rustwasm/wasm-pack
-
 ## Installation
 
-The recommend way to install the `wasm-bindgen` command line tool is with the
-`wasm-pack` installer described
-[here](https://rustwasm.github.io/wasm-pack/installer/). After installing
-`wasm-pack`, you are ready to build project invoking `wasm-pack build`.
-This command installs apropriate version of the `wasm-bindgen` command-line
-tool. The version of `wasm-bindgen` installed by `wasm-pack` is not available
- to be used directly via command line.
-
-It is not recommended to install `wasm-bindgen-cli` as its version must match
-_exactly_ the version of `wasm-bindgen` that is specified in the project's
-cargo.lock file. Using `wasm-pack` for building simplifies the build process
-as `wasm-pack` ensures that the proper version of `wasm-bindgen` command-line
-tool is used. That means that `wasm-pack` may install many different versions
-of `wasm-bindgen`, but during the build `wasm-pack` will always make sure to
-use the correct one.
-
-Note: if, for any reason, you decide to use wasm-bindgen directly (this is
-not recommended!) you will have to manually take care of using exactly the
-same version of wasm-bindgen command-line tool (wasm-bindgen-cli) that
-matches the version of wasm-bingden in cargo.lock.
-
+```
+cargo install -f wasm-bindgen-cli
+```
 
 ## Usage
 

guide/src/reference/deployment.md

@@ -6,8 +6,7 @@ as documentation for the various known options, and as always PRs are welcome
 to update this if it's out of date!
 
 The methods of deployment and integration here are primarily tied to the
-`--target` flag. Note that the `--target` flag of `wasm-pack` and `wasm-bindgen`
-should behave the same way in this respect. The values possible here are:
+`--target` flag.
 
 | Value           | Summary                                                    |
 |-----------------|------------------------------------------------------------|
@@ -55,8 +54,7 @@ If you're not using a bundler but you're still running code in a web browser,
 `--target web` flag. You can check out a [full example][nomex] in the
 documentation, but the highlights of this output are:
 
-* When compiling you'll pass `--target web` to `wasm-pack` (or `wasm-bindgen`
-  directly).
+* When compiling you'll pass `--target web` to `wasm-bindgen`
 * The output can natively be included on a web page, and doesn't require any
   further postprocessing. The output is included as an ES module.
 * The `--target web` mode is not able to use NPM dependencies.
@@ -79,8 +77,7 @@ information about `--target no-modules`.
 **`--target nodejs`**
 
 If you're deploying WebAssembly into Node.js (perhaps as an alternative to a
-native module), then you'll want to pass the `--target nodejs` flag to
-`wasm-pack` or `wasm-bindgen`.
+native module), then you'll want to pass the `--target nodejs` flag to `wasm-bindgen`.
 
 Like the "without a bundler" strategy, this method of deployment does not
 require any further postprocessing. The generated JS shims can be `require`'d