Intent to Implement: JavaScript module import()

[Sathya Gunasekaran]

Contact emails

V8 implementation: gsa...@chromium.org

Blink implementation: kou...@chromium.org

Spec: dom...@chromium.org

Spec

JavaScript side: https://tc39.github.io/proposal-dynamic-import/

This is a stage 3 proposal, which per the TC39 process is the appropriate time to implement (and ship).

Web side: https://github.com/tc39/proposal-dynamic-import/blob/master/HTML%20Integration.md

This is a (detailed) draft which will be integrated into HTML shortly.

Summary

import() is an addition to the JavaScript module system which allows dynamic importing of modules, as opposed to the static/declarative importing provided by the import declaration. It is a new JavaScript "function-like" syntactic form, similar to super().

Motivation

(From https://github.com/tc39/proposal-dynamic-import#motivation-and-use-cases)

The existing syntactic forms for importing modules are static declarations. They accept a string literal as the module specifier, and introduce bindings into the local scope via a pre-runtime "linking" process. This is a great design for the 90% case, and supports important use cases such as static analysis, bundling tools, and tree shaking.

However, it's also desirable to be able to dynamically load parts of a JavaScript application at runtime. This could be because of factors only known at runtime (such as the user's language), for performance reasons (not loading code until it is likely to be used), or for robustness reasons (surviving failure to load a non-critical module). Such dynamic code-loading has a long history, especially on the web, but also in Node.js (to delay startup costs). The existing `import` syntax does not support such use cases.

Truly dynamic code loading also enables advanced scenarios, such as racing multiple modules against each other and choosing the first to successfully load.

---

Today this is also possible via dynamically creating and inserting <script type="module"> elements. However, this has a number of disadvantages. See https://github.com/tc39/proposal-dynamic-import#using-host-specific-mechanisms for more information on that comparison.

Interoperability and Compatibility Risk

This is a mature feature in the TC39 process, implying at least support from at least all JavaScript engine teams at each browser. We anticipate it being implemented rapidly, either alongside initial implementations of JavaScript modules or shortly thereafter.

Edge: Public support

Firefox: Public support

Safari: Shipped in Safari Tech Preview

Web developers: Positive

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

https://crbug.com/711706

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5684934484164608

Requesting approval to ship?

Not yet, but hopefully soon!

[Zac Hansen]

Is this related, in any way, to https://v8.paulfryzel.com/docs/master/classv8_1_1_module.html ?

Will this documentation be updated as a part of this implementation, if appropriate?

[Sathya Gunasekaran]

On Wed, Jul 5, 2017 at 7:56 PM, Zac Hansen <xax...@gmail.com> wrote:
> Is this related, in any way, to
> https://v8.paulfryzel.com/docs/master/classv8_1_1_module.html ?
>
> Will this documentation be updated as a part of this implementation, if
> appropriate?
>

The relevant documentation is here:
https://cs.chromium.org/chromium/src/v8/include/v8.h?l=6120&rcl=b520c6ed5eadf29b950a0fc567a327b93c48c02d

The tracking bug for V8
(https://bugs.chromium.org/p/v8/issues/detail?id=5785) has more
information (including a design doc).

[Adam Klein]

Good news: this is already part of the spec (and this implementation).

For module scripts (loaded either via <script type=module>, an import declaration in a module script, or via this new import() API), the HTML spec requires an appropriate JavaScript mime type. See https://html.spec.whatwg.org/#fetch-a-single-module-script step 7 for the spec text.

On Thu, Jul 6, 2017 at 11:37 AM, drx via blink-dev <blin...@chromium.org> wrote:

This is a good opportunity to get more strict about content type validation.

It looks like the current behavior in Chrome is that specific media content types (png, etc.) will not be loaded as script, but other non-script types (at least application/octet-stream and text/plain) will load as script.

I'd like to propose that import() switch to an allow-list strategy.  Since import() is a new API, we have the ability to lock down here without breaking existing sites.  Maybe it's not too late to do the same with the import statement as well.

Would it be appropriate to include the allow-list requirement in either of the specs associated with this intent to implement?

I bounced this around some web security folks within Google and there is agreement that an allow-list would be a good thing.  Also, from Eric Lawrence:

> Mike West sounds on board; he'd made the original fix which blocks image/*.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb097e57-c600-44ed-9901-c8d04d01580a%40chromium.org.