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. import whatever from 'whatever.js' if { integrity: 'sha256-deadbeefabcdefg' }) and/or CSP nonces/hashes? That would be exciting.

@mikewest we are focusing on the type attribute for now but we are open to add more in the future. I'm not sure it's well suited for SRIs because you would want a centralized location when updating them, but technically possible yes.

@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

@MylesBorins

// 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.

We took another look at this during some TAG breakouts this week. Overall we're happy with the approach you're taking, and we're especially happy that TC39 is tackling this problem, as it will unblock features like JSON Modules #375 and CSS Modules #405.