tc39 / proposal-dynamic-import

import() proposal for JavaScript

Home Page:https://tc39.github.io/proposal-dynamic-import/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add import request options

sanderd17 opened this issue · 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.

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.

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

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

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

Just like a fetch, with an init object ;)

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

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

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