Test plan for import bytes

[styfle]

Proposal repo: https://github.com/tc39/proposal-import-bytes

• import empty bytes
• import txt bytes
• import png bytes
• dynamic import bytes
• import twice idempotency?

[ljharb]

• import JS as bytes
• import JSON as bytes

[nicolo-ribaudo]

For the two suggested by @ljharb, it'd be great to also have wpt tests that serve those files with the corresponding mime type.

Also, test262 tests for a file imported both as json/js and as bytes.

[ptomato]

Some more suggestions:

• files with potentially troublesome \0 characters, like a UTF-8 text file followed by a \0 followed by more text
• files with potentially troublesome encoding, like invalid UTF-8
• results are always backed by an immutable ArrayBuffer

[nicolo-ribaudo]

Also, note that the proposal doesn't actually say anything about encoding or about the content of the Uint8Array. It would be valid for a file to contain a random list of bytes and for the Uint8Array to contain a different list of bytes.

[ptomato]

It would be valid for a file to contain a random list of bytes and for the Uint8Array to contain a different list of bytes.

What? Surely that's an omission in the proposal, then.

[nicolo-ribaudo]

The proposal doesn't deal with I/O, it only says "when you use the type: "bytes" attribute, either error or give me an Uint8Array around an Immutable array buffer". The process of getting those bytes to JavaScript is entirely host-defined, for example Node.js will deal with a filesystem while the web will fetch.

A lot of the tests for this proposal will probably need to be in WPT.

[ptomato]

I think we have to make at least some concession to practicality here...

[bakkot]

Ecma262 doesn't say anything about encoding of ES modules either. I think we can make at least the same assumptions that we use for testing imports of ES modules which are represented as files on disk. But I do think any trickier encoding-related stuff (byte-order marks or whatever) should be left for WPT.