Add support for Blob

[joanlopez]

What?

It adds support for Blob, as described in #35

Why?

In order to stabilize the API before considering the extension non-experimental.

Checklist

• I have performed a self-review of my code.
• I have added tests for my changes.
• I have run linter locally (make lint) and all checks pass.
• I have run tests locally (make test) and all tests pass.
• I have commented on my code, particularly in hard-to-understand areas.

Related PR(s)/Issue(s)

Closes #35

[olegbespalov]

No specific feedback from my side, what Mihails said + linter fixes sounds like to plan to address 👍

nit: There are few places where we just throw an error like common.Throw(rt, err), I'd suggest add some context by wrapping the error

[olegbespalov]

Looks good to me!

Please also update README.md since it contains some Blob references that become misleading after merging this 👍

[olegbespalov]

🚀

[mstoykov]

LGTM in general but is missing the fairly important part of using Blob to send data.

So I will be requesting that as well on top of some nitpicks and the dependency updates :)

[joanlopez]

I'm open for suggestions, although none of the ones I've seen so far really convinces me. If you prefer any other, just tell me.

[joanlopez]

LGTM in general but is missing the fairly important part of using Blob to send data.

So I will be requesting that as well on top of some nitpicks and the dependency updates :)

Hey @mstoykov,

On top of nitpicks, I've added a bunch of changes:

• Extended the support to construct new Blobs for all the types described in the spec (ArrayBuffers, TypedArrays, DataViews, Blobs, strings, or a mix of any of such elements)
• Added support for the type attribute (now assigned from constructor options)
• Added support for the missing methods: bytes(), slice() and stream().
• Changed the return type of some of these methods to Promise, as described in the spec: arrayBuffer(), bytes() and text().
• Added support to also use Blob for sending.

So, with all that, I think we're in a quite decent position (after your review), to ship this support, as I think it's quite compliant.
That said, I'd recommend you to take a look at all these changes by following the commit history in order, as it's probably easier to follow, specially considering that you already did a review. Just in case.

Thanks! 🙇🏻

Re-review requested

[mstoykov]

LGTM in general, but the isBlob part is actually blocking.

I will be glad to have more tests especially if we can get some suite working, but we can have this after we merge this.

[joanlopez]

LGTM in general, but the isBlob part is actually blocking.

Fixed, thanks to your suggestion! 🙇🏻

I will be glad to have more tests especially if we can get some suite working, but we can have this after we merge this.

To be honest, after my experience with Streams API, and considering that experience wasn't smooth for other extensions (see grafana/xk6-webcrypto#81), I'd prefer to wait until we either make this extension part of k6-core or we make k6 surface for extensions that want to test against WPTs more reusable.

In fact, arguably that could even be considered a requirement if we eventually support dynamic extension (more chances to keep extension isolated). Also, considering v1.0 guarantees, we can try to think about something reusable that isn't strictly part of k6 core surface/guarantees.

In any case, I'd prefer to move on and postpone that discussion. I can create an equivalent of grafana/xk6-webcrypto#81 for this extension, if you want.

All that said, as I mentioned here, I did code this implementation within the k6 code base locally, so we don't have checks in place for future chances, but technically this implementation is already partly compliant with WPTs. It's something.