This is intended to handle #1458 and #822. These issues stem from
behavior where:
wasm-pack test --node
will actually run both Node.js and browser tests! Two new env vars are
read here, `WASM_BINDGEN_TEST_ONLY_{NODE,WEB}`, which control which
tests are executed by `wasm-bindgen-test-runner`. The intention is that
these will be set by `wasm-pack` to configure which tests are run, and
if test suites are skipped due to the env vars we'll print an
informational message indicating how they can be run.
Closes#822Closes#1458
This commit enables `[NoInterfaceObject]` annotated interfaces in
`web-sys`. The `NoInterfaceObject` attribute means that there's not
actually a JS class for the object, but all of its properties and such
can still be accessed structually and invoked. This should help provide
more bindings for some more common types on the web!
Note that this builds on recent features to ensure that `dyn_into` and
friends always fail for `NoInterfaceObject` objects because they don't
actually have a class.
Closes#893Closes#1257Closes#1315
This commit switches to executing `rustfmt` by default on
`web-sys`-generated bindings. This improves situations like "view
source" in Rustdoc as well as the IDE interactive debugging experience.
This was initially disabled by default because `rustfmt` took so long to
execute, but nowadays `web-sys` is by default much smaller so there's
much less need to avoid running `rustfmt` in fear of it taking too
long.
Closes#1457
Treats any object of shape `{ next: function }` as an iterator via new `is_type_of` method. This is consistent with JavaScript iteration protocol which we already respect.
Also fixes a minor issue that `is_function` was unnecessarily called twice (once explicitly and once as part of `dyn_into` which now does the same check).
This commit adds `#[derive(PartialEq, Eq)]` to many types throughout
`js-sys`. These types are basically all based on `Object`, which means
that `Object.is` can be used for `PartialEq` and the `Eq` requirements
are upheld.
The macro has also been updated to internally store the deref target
instead of unconditionally storing `JsValue`, allowing `#[derive]` to
work a bit better in these situations.
* Ensure `PartialEq` is implemented from these types to native Rust types
* Implement `From` between these type and native Rust types
* Deprecated `Number::new` and `Boolean::new` to discourage use of the
object forms, recommending the `from` constructors instead.
Closes#1446
The last write accidentally wasn't accounted for in the returned length
of the string and we unfortunately don't have any test coverage of
`encodeInto` since it requires Firefox nightly right now (and doesn't
work in Node yet).
Closes#1436
This commit adds an intrinsics to the `wasm_bindgen` crate which
accesses the `WebAssembly.Table` which is the function table of the
module. Eventually the thinking is that a module would import its own
function table via native wasm functionality (via `anyref` and such),
but until that's implemented let's add a binding for it ourselves!
Closes#1427
This commit aims to address #1348 via a number of strategies:
* Documentation is updated to warn about UTF-16 vs UTF-8 problems
between JS and Rust. Notably documenting that `as_string` and handling
of arguments is lossy when there are lone surrogates.
* A `JsString::is_valid_utf16` method was added to test whether
`as_string` is lossless or not.
The intention is that most default behavior of `wasm-bindgen` will
remain, but where necessary bindings will use `JsString` instead of
`str`/`String` and will manually check for `is_valid_utf16` as
necessary. It's also hypothesized that this is relatively rare and not
too performance critical, so an optimized intrinsic for `is_valid_utf16`
is not yet provided.
Closes#1348
Because of some incorrect use of `js.push_str(..)`, we could sometimes emit code
before the ES modules imports, which is syntactically invalid:
const __exports = {};
import { Thing } from '...'; // Syntax error!
This has been fixed by making sure that the correct `imports` or `imports_post`
string is built up. We now also assert that the `js` string is empty at the
location where we add imports if we're using ES modules.
