Skip to content
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

Closed
1 task done
xtuc opened this issue Jul 12, 2020 · 11 comments
Closed
1 task done

Import Conditions #535

xtuc opened this issue Jul 12, 2020 · 11 comments

Comments

@xtuc
Copy link

xtuc commented Jul 12, 2020

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:

  • 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
Copy link

littledan commented Jul 13, 2020

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
Copy link

mikewest commented Jul 14, 2020

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
Copy link
Author

xtuc commented Jul 14, 2020

@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
Copy link

littledan commented Jul 14, 2020

@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
Copy link

frank-dspeed commented Jul 14, 2020

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
Copy link

MylesBorins commented Jul 14, 2020

@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
Copy link

frank-dspeed commented Jul 14, 2020

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

@frank-dspeed
Copy link

frank-dspeed commented Jul 14, 2020

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
Copy link

frank-dspeed commented Jul 14, 2020

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

@hober hober self-assigned this Jul 15, 2020
@hober hober added Topic: components Topic: scripting ECMA, Web Assembly bindings, etc. Venue: TC39 labels Jul 15, 2020
@kenchris kenchris self-assigned this Jul 15, 2020
@torgo torgo added this to the 2020-07-27-week milestone Jul 15, 2020
@xtuc
Copy link
Author

xtuc commented Jul 16, 2020

@hober
Copy link
Contributor

hober commented Aug 5, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants