-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Import Conditions #535
Comments
Apologies for filing this issue a bit late, with the TC39 meeting coming up in just a week. I want to note that we're very interested in feedback even if it comes after that meeting. In particular, the HTML integration would need to be agreed on before shipping, is not within the scope of this meeting (we'll discuss it but won't decide on it). The TAG's thoughts here could be very helpful on this question of whether the import conditions form part of the module map key in HTML, discussed further at whatwg/html#5640 and whatwg/html#5658 |
Could this mechanism also allow imports to integrate with SRI (e.g. |
@mikewest we are focusing on the |
@mikewest Including the integrity inline wouldn't work very well with circiular module dependencies, and the whole module tree's integrity hashes would need to be updated if a deep dependency is updated (so, bad for caching). It would seem more optimal to have an out-of-band resource to include integrity hashes for all subresources, rather than treating JS specially here. That said, if we ignored those problems, I think an integrity condition would fit in just fine with the import conditions design. |
The road is clear with dynamic import and TLA we got everything needed to serve something in any formart we should not over-engineer TLI Top Level Import.!!! when const myFetchFunction = x=>fetch(x)
await myFetchFunction('import-json.json').then(x=>/*do something with it */) while chunk can have any ECMAScript supported types like string or buffer. Transform simply gets the rawChunk emited by fetch and then returns after generator finished |
@frank-dspeed we have everything for dynamically grabbing these resources, but not for statically getting them. There is a massive advantage to being able to fetch / parse the JSON object asynchronously during the fetch phase of the module loader. |
@MylesBorins what about serviceWorker + Worker ? where is the problem? |
maybe i am getting that wrong but i think with serviceWorkers + Workers and Stream Api we can incremental parse on load on a external TH |
// Fetch the original image
fetch('./tortoise.png')
// Retrieve its body as ReadableStream
.then(response => response.body)
.then(body => {
const reader = body.getReader()
return new ReadableStream({
start(controller) {
return pump();
function pump() {
return reader.read().then(({ done, value }) => {
// When no more data needs to be consumed, close the stream
if (done) {
controller.close();
return;
}
// Enqueue the next data chunk into our target stream
controller.enqueue(value);
return pump();
});
}
}
})
})
.then(stream => new Response(stream))
.then(response => response.blob())
.then(blob => URL.createObjectURL(blob))
.then(url => console.log(image.src = url))
.catch(err => console.error(err)); |
@frank-dspeed can you please create issues against https://github.com/tc39/proposal-import-conditions or https://github.com/tc39/proposal-top-level-await. |
Saluton TAG!
I'm requesting a TAG review of Import Conditions.
The Import Conditions and JSON modules proposal adds:
An inline syntax for module import statements to pass on more information alongside the module specifier.
An initial application for such attributes in supporting JSON modules in a common way across JavaScript environments.
Further details:
We'd prefer the TAG provide feedback as:
💬 leave review feedback as a comment in this issue and @-notify @xtuc @littledan @MylesBorins @dandclark
The text was updated successfully, but these errors were encountered: