Skip to content
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.

Add import request options #76

Open
sanderd17 opened this issue May 16, 2019 · 8 comments
Open

Add import request options #76

sanderd17 opened this issue May 16, 2019 · 8 comments

Comments

@sanderd17
Copy link

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.

@sashafirsov
Copy link

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.

@Lcfvs
Copy link

Lcfvs commented May 22, 2019

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

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

@Alhadis
Copy link

Alhadis commented May 22, 2019

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

@Lcfvs
Copy link

Lcfvs commented May 22, 2019

Just like a fetch, with an init object ;)

@Alhadis
Copy link

Alhadis commented May 22, 2019

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"})

@Lcfvs
Copy link

Lcfvs commented May 22, 2019

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

@pauldraper
Copy link

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

@Lcfvs
Copy link

Lcfvs commented Jul 18, 2020

@pauldraper Mines?

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

No branches or pull requests

5 participants