Wasm-bindgen: Publish the `js-sys` crate

[fitzgen]

I think we have enough bindings written that it would be useful to publish now. Especially since it is a separate crate from wasm-bindgen now.

Things we need to do first:

• [x] Do a once over of the bindings to double check we aren't returning Number objects and all that

• [X] Decide on a version. Do we want to match wasm-bindgen or start at 0.1.0?

• [x] #[derive(Clone, Debug)] on all the extern types

• [x] Make sure we are always passing by-ref

• [x] Agree on &str vs &JsString arguments

[fitzgen]

I think we should probably reset to 0.1.0 since the whole point of a separate crate is the freedom to publish independently and not be super tied together.

[data-pup]

Assuming that wouldn't have any sort of negative ergonomic effect on people using these crates, resetting to 0.1.0 makes sense to me, especially if they are separate. That said, my opinion is not strongly held by any means, and would defer to y'all's opinions on it :)

[alexcrichton]

Sounds good to me! (along with 0.1.0)

[alexcrichton]

Some things I've noticed working with this crate:

• Strings are somewhat inconsistent, sometimes arguments are &str, others are JsString
• It's inconsistent whether arguments are by-ref or by-value
• In writing tests I've noticed a few small errors.
• Some methods expose all the options while others only expose some.

[fitzgen]

Strings are somewhat inconsistent, sometimes arguments are &str, others are JsString

I think these should always be &JsString. That way, we can let users choose if/when to make the copy from the JS heap into wasm linear memory. When host bindings are a thing that is actually happening, we can revisit to match what is fastest for them.

It's inconsistent whether arguments are by-ref or by-value

I think we should use by-ref to avoid ref-count noise.

Some methods expose all the options while others only expose some.

I don't think this needs to block publishing 0.1.0, since there are just so many optional arguments to various functions and methods, and it seems we have some design decisions to make about this topic.

We have been choosing whether to expose these arguments on a case by case basis and by applying our own judgement.

As I see it, we have a few choices:

• Continue applying our own judgement on a case by case basis
• Expose every argument
• Expose only the required arguments
• Add multiple bindings to the same function, some with optional arguments, some without. Do we do every combination of optional arguments? Always require first N arguments are supplied (so N+1 versions of the function for N optional arguments)?

[alexcrichton]

I'm less certain about using &JsString all over the place, it's actually a lot faster to use &str if you don't reuse the JsString elsewhere because that way you only cross the wasm boundary once instead of N + 1 (where N is the number of strings). I'm not sure how often one is used over the other, but I'm personally partial to a strategy where we support both (through methods like fn parse(&str) and fn parse_js(&JsString)).

I do agree though we should probably take by-ref everywhere!

For optional arguments I think it's fine to basically cut what we have. It's subpar in some places but it can always be worked around locally if necessary or we can have more releases.

One last thing I've realized is we probably want to #[derive(Clone, Debug)] all the types here as well, but that won't be too hard to do!

[toVersus]

This is quite trivial thing, but can we resolve the inconsistency whether semblance of "C" should be declared or not, which @alexcrichton pointed out before in #422? I am using rustfmt and it frustrates me to complement semblance (and put some indentations) whenever applying changes to the code.

[fitzgen]

@toVersus I personally agree we should just switch to using rustfmt for styling, but it definitely isn't a blocker for publishing the js-sys crate.

[fitzgen]

Will publish tomorrow, if anyone has any last minute concerns, now is your time to voice them!

[fitzgen]

Published! https://crates.io/crates/js-sys

[fitzgen]

Announced! https://rustwasm.github.io/2018/07/26/announcing-the-js-sys-crate.html