The cdylib's name can be overriden by lib.name

[konstin]

🐛 Bug description

Currently, wasm-pack assumes the cdylib's name is the crate name with underscores and .wasm as extension, while this value can be overwritten by lib.name in Cargo.toml.

👟 Steps to reproduce

Cargo.toml

[package]
name = "foo"
version = "0.1.0"
authors = ["konstin <konstin@mailbox.org>"]

[lib]
crate-type = ["cdylib"]
name = "bar" # <- "Renames" the artifact to bar.wasm

[dependencies]
wasm-bindgen = "0.2.22"

src/lib.rs

#[cfg(test)]
mod tests {
    #[test]
    fn it_works() {
        assert_eq!(2 + 2, 4);
    }
}

Output of wasm-pack build --mode no-install --debug

  [1/6] Checking crate configuration...
  [2/6] Compiling to WASM...
  [3/6] Creating a pkg directory...
  [4/6] Writing a package.json...
  :-) [WARN]: Field 'description' is missing from Cargo.toml. It is not necessary, but recommended
  :-) [WARN]: Field 'repository' is missing from Cargo.toml. It is not necessary, but recommended
  :-) [WARN]: Field 'license' is missing from Cargo.toml. It is not necessary, but recommended
  [5/6] Copying over your README...
  :-) [WARN]: origin crate has no README
| [6/6] Running WASM-bindgen...
wasm-bindgen failed to execute properly. stderr:

error: failed to read `target/wasm32-unknown-unknown/debug/foo.wasm`
	caused by: No such file or directory (os error 2)

🖥️ Relevant code

wasm-pack/src/manifest/mod.rs

Lines 264 to 267 in 120236f

	/// Get the crate name for the crate at the given path.
	pub fn get_crate_name(path: &Path) -> Result<String, Error> {
	Ok(read_cargo_toml(path)?.package.name)
	}

And wasm_bindgen_build

🤔 Expected Behavior

While checking for lib.name would fix this particular issue, it's definitely not future proof and I assume there are already cases today where this still wouldn't work.

One solution would be asking cargo through cargo metadata. Relevant excerpt:

{
  "packages": [
    {
      "name": "c",
      "version": "0.1.0",
      "id": "c 0.1.0 (path+file:///home/konsti/wasm-pack/c)",
      "license": null,
      "license_file": null,
      "description": null,
      "source": null,
      "dependencies": [
        {
          "name": "wasm-bindgen",
          "source": "registry+https://github.com/rust-lang/crates.io-index",
          "req": "^0.2.22",
          "kind": null,
          "rename": null,
          "optional": false,
          "uses_default_features": true,
          "features": [],
          "target": null
        }
      ],
      "targets": [
        {
          "kind": [
            "cdylib"
          ],
          "crate_types": [
            "cdylib"
          ],
          "name": "d",
          "src_path": "/home/konsti/wasm-pack/c/src/lib.rs",
          "edition": "2015"
        }
      ],
      "features": {},
      "manifest_path": "/home/konsti/wasm-pack/c/Cargo.toml",
      "metadata": null,
      "authors": [
        "konstin <konstin@mailbox.org>"
      ],
      "categories": [],
      "keywords": [],
      "readme": null,
      "repository": null,
      "edition": "2015"
    },
  ]
}

The other option would be to use the info from --message-format=json in #333 to get the target name. This is e.g. the prettified last line from cargo build -q --message-format json --target wasm32-unknown-unknown:

{
  "features": [],
  "filenames": [
    "/home/konsti/wasm-pack/foo/target/wasm32-unknown-unknown/debug/bar.wasm"
  ],
  "fresh": true,
  "package_id": "foo 0.1.0 (path+file:///home/konsti/wasm-pack/foo)",
  "profile": {
    "debug_assertions": true,
    "debuginfo": 2,
    "opt_level": "0",
    "overflow_checks": true,
    "test": false
  },
  "reason": "compiler-artifact",
  "target": {
    "crate_types": [
      "cdylib"
    ],
    "edition": "2015",
    "kind": [
      "cdylib"
    ],
    "name": "bar",
    "src_path": "/home/konsti/wasm-pack/foo/src/lib.rs"
  }
}

Both solutions would supersede #25.

❔ Unresolved question

Should the lib name influence how the exports are named? Like we could use const js = import("@MYSCOPE/c/d.js"); in the example.