proposal-dynamic-import icon indicating copy to clipboard operation
proposal-dynamic-import copied to clipboard

Add import request options

Open sanderd17 opened this issue 5 years ago • 8 comments

To me, import on the browser looks like a http request followed by evaluation of the code.

But with http requests (like on the fetch function), you can add extra data: authentication, a body, etc. See documentation on the fetch function

I don't see that specified here, so I guess it doesn't exist in this proposal. But is there a reason why it doesn't exist?

Adding a body would be handy f.e. to specify a version of a module. Adding authentication would make it easier to keep your code private. Basically just the same reasons fetch supports request options.

sanderd17 avatar May 16 '19 17:05 sanderd17

The use cases for altering http requests in import would become unlimited if not only request parameters but also response accounted.

For example ajax with Content-Type "application/json" is called often once on page, making it perfect candidate for import. Not to mention html or Xslt as template for widgets.

If we are engaged in http in/out parameters, would be useful to be able to have handlers for error and success. Handler( responce ) would pre-process responce accounting http code, headers, payload and returning Promise resolved with value for import.

In short, make native import capable webpack things. With proper handlers in place for most popular content types, webpacking would not be necessary. I guess there is no need to elaborate why webpack is in such demand now. One of answers is that native import does not support different content and path mappings.

sashafirsov avatar May 18 '19 15:05 sashafirsov

Imho, the import misses some other very important fetch's options:

  • the redirect control
  • the integrity check
  • the referrer strategy

Lcfvs avatar May 22 '19 07:05 Lcfvs

How would this work with built-in modules? E.g., import("fs")

Alhadis avatar May 22 '19 07:05 Alhadis

Just like a fetch, with an init object ;)

Lcfvs avatar May 22 '19 07:05 Lcfvs

I'm talking mainly about subresource integrity. If a checksum is given and a built-in/native module is specified, should it be ignored? Throw an error? Or attempt to verify integrity of a (presumably inaccessible) internal resource?

In other words, what should be the expected behaviour here...?

import("fs", {integrity: "sha256-492f9cd931b84a1b1ad73b22eb8a096331e67dc38043e908de352c29343e27fb"})

Alhadis avatar May 22 '19 07:05 Alhadis

Imho, just throw an error, yes, as for a not found module, since the expected module isn't found.

Lcfvs avatar May 22 '19 07:05 Lcfvs

All of these concerns exist for static imports as well; it should really be a different proposal and include suggestions for those.

pauldraper avatar Jul 15 '20 03:07 pauldraper

@pauldraper Mines?

Lcfvs avatar Jul 18 '20 13:07 Lcfvs