Why not import bytes xxx from xxx?

[LongTengDao]

because bytes, source, defer seems conflict step for same target

[styfle]

Can you give an example of the problem (and example of your suggested solution)?

[bakkot]

@styfle As I understand it the question is, why is the shape of the syntax import whatever from "./photo.png" with { type: "bytes" }; rather than import bytes whatever from "./photo.png", given that it doesn't really make sense to combine type: "bytes" with import source or import defer.

Which is a fair question, but given that type: "json" has already shipped, I think the precedent for putting type in the attributes section rather than making a new import form is well established.

Personally I think of it as, we use a new import form like import defer when we're fundamentally changing the machinery at a language level, and we use attributes like type: "bytes" when just telling the host what kind of module we're asking for.

[0f-0b]

I think the technical reason for this is that, because a host is not allowed to load different modules based on the import phase, if a browser host were to implement bytes as a phase, it would necessarily lead to the undesirable consequence that import bytes whatever from "./photo.png" in a <script> element sends a request with the value of the Sec-Fetch-Dest header set to script instead of something reasonable like empty.

[LongTengDao]

@styfle As I understand it the question is, why is the shape of the syntax import whatever from "./photo.png" with { type: "bytes" }; rather than import bytes whatever from "./photo.png", given that it doesn't really make sense to combine type: "bytes" with import source or import defer.

Which is a fair question, but given that type: "json" has already shipped, I think the precedent for putting type in the attributes section rather than making a new import form is well established.

Personally I think of it as, we use a new import form like import defer when we're fundamentally changing the machinery at a language level, and we use attributes like type: "bytes" when just telling the host what kind of module we're asking for.

That depends on what sematic it is designed for (and the future vision).

1. import x from 'x' with { type: 'bytes' }

Like application/octet-stream, which means "other unknown mime type" (binary type just is coincidence), and may or maynot make different Accept HTTP header, and get different response (though rarely, depend on hostAgent and server).

import xxx from 'x' with { type: 'json' };
import xxx from 'x' with { type: 'css' };
import xxx from 'x' with { type: 'bytes' };

<script src="x" type="importmap"></script>
<link href="x" rel="stylesheet" />
<img src="x" />

2. import bytes x from 'x'

Which means "the binary phase" for same asset (unique HTTP cache for same specifier and type attribute).

	binary phase (TypedArray etc.)	encoding phase (string)	compiling phase	prepare phase (sideEffects when TLA)	instantiation phase (sideEffects)
.js	import bytes x from 'x'	import text x from 'x'	import source x from 'x' (ModuleSource/Declaration/Expression)	import defer * as x from 'x' (NamespaceObject)	import * as x from 'x' (NamespaceObject)
.json	import bytes x from 'x' with { type: 'json' }	import text x from 'x' with { type: 'json' }	import source x from 'x' with { type: 'json' } (ModuleSource/Declaration/Expression)	meaningless	import x from 'x' with { type: 'json', subtype?: 'record and tuple' } (value)
.wasm	import bytes x from 'x' with { type: 'wasm' }	meaningless	import source x from 'x' with { type: 'wasm' } (WebAssembly.Module)	meaningless	meaningless (unless no imports)
.css	import bytes x from 'x' with { type: 'css' }	import text x from 'x' with { type: 'css', encoding?: 'utf-8' }	import source x from 'x' with { type: 'css', encoding?: 'utf-8' } (CSSStyleSheet)	meaningless	import 'x' with { type: 'css', encoding?: 'utf-8' }
.png	import bytes x from 'x' with { class?: 'DataView' }	meaningless	meaningless	meaningless	meaningless
.txt	import bytes x from 'x' with { class?: 'Uint16Array' }	import text x from 'x' with { encoding?: 'utf-16le', fatal?: '', bom?: '' }	meaningless	meaningless	meaningless

[bakkot]

The intention is that this always gives you a Uint8Array, regardless of what the resource you're requesting is. It doesn't make sense to say import bytes x from 'x' with { type: 'css' } because the fact that the resource you're importing happens to be CSS is irrelevant to this kind of import.

[LongTengDao]

The intention is that this always gives you a Uint8Array, regardless of what the resource you're requesting is. It doesn't make sense to say import bytes x from 'x' with { type: 'css' } because the fact that the resource you're importing happens to be CSS is irrelevant to this kind of import.

different combination of specifier and type attribute lead to:

1. different resolve chance in nodejs hooks and rollup plugins
2. different http request cache in browser which may or maynot be same (edition or version), and different net cost
3. different Accept http request header in browser

(they are treated as two "url")

while same combination directly using same cache.

they are different semanic. both make sence, but need to explictly decide and clarify in spec, to avoid incorrectly community usage and implementation, which mislead and block the future proposals' designing.

the reason using word "type:bytes" (anyFetched.bytes()) imply actually import bytes xxx from anything with anytype usage. if this proposal really aim at "application/octet-stream" semantic, maybe "type:octet", "type:binary", or other good enough value will be better.

[nicolo-ribaudo]

This proposal is not specific to any HTTP header or mime type, since those concepts are web-specific and not generic for JavaScript platforms. How networks and filesystems work is also specific to different platforms, and not generic of how JavaScript works, so all this proposal can do is say "platforms implementing JavaScript must give a way, whatever it will be, to import a module as an Uint8Array".

JavaScript doesn't have any requirements or any assumption about how modules are retrieved, as long as for JavaScript modules there is a string representation (a "sequence of unicode code points", with no further assumption about encoding). The fact that the module is a specific file stored somewhere as binary memory is entirely platform-specific, so it's not really something that could be represented as a "phase in JavaScript's module system".

the reason using word "type:bytes" (anyFetched.bytes()) imply actually import bytes xxx from anything with anytype usage. if this proposal really aim at "application/octet-stream" semantic, maybe "type:octet", "type:binary", or other good enough value will be better.

I think "type: binary" would be similarly good to "type: bytes": it represents some raw memory corresponding to the module in the platform-defined way. However, I prefer "type: bytes" since it doesn't only tell what it is, but also how it is exposed to JS code.