Import Conditions

[xtuc]

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.

• Explainer¹ (minimally containing user needs and example code): https://github.com/tc39/proposal-import-conditions/blob/master/README.md
• Specification URL: https://tc39.es/proposal-import-conditions, Reland JSON module scripts whatwg/html#5658
• Tests: we plan to write tests after HTML integration is agreed on and Stage 3 is reached
• Security and Privacy self-review²: https://github.com/tc39/proposal-import-conditions/blob/master/tag-security-and-privacy.md
• GitHub repo (if you prefer feedback filed there): https://github.com/tc39/proposal-import-conditions/issues
• Primary contacts (and their relationship to the specification):
  • Sven Sauleau (@xtuc), Babel
  • Daniel Ehrenberg (@littledan), Igalia
  • Myles Borins (@MylesBorins), GitHub
  • Dan Clark (@dandclark), Microsoft
• Organization(s)/project(s) driving the specification: Babel, Igalia, GitHub, Microsoft
• Key pieces of existing multi-stakeholder review or discussion of this specification: Integration with import-attributes whatwg/html#5640, https://github.com/tc39/notes/blob/27b0afb98a2d212c24345dc101fa9803ba6e8377/meetings/2020-06/june-3.md#module-attributes-for-stage-2
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): Import Attributes mozilla/standards-positions#373

Further details:

• I have reviewed the TAG's API Design Principles
• Relevant time constraints or deadlines: we are planning to ask Stage 3 at the July 2020 TC39 meeting (20th-23rd)
• The group where the work on this specification is currently being done: TC39
• The group where standardization of this work is intended to be done: TC39
• Major unresolved issues with or opposition to this specification: determining whether the import conditions form part of the module map key.
• This work is being funded by: Bloomberg for Igalia

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify @xtuc @littledan @MylesBorins @dandclark

[littledan]

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

[mikewest]

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.

[xtuc]

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

[littledan]

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

[frank-dspeed]

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

[MylesBorins]

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

[frank-dspeed]

@MylesBorins what about serviceWorker + Worker ? where is the problem?

[frank-dspeed]

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

[frank-dspeed]

@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));

[xtuc]

@frank-dspeed can you please create issues against https://github.com/tc39/proposal-import-conditions or https://github.com/tc39/proposal-top-level-await.

[hober]

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.