Intent to Implement: <script type="module">

[Adam Klein]

Contact emails

ad...@chromium.org

Spec

https://html.spec.whatwg.org/#the-script-element:module-script

https://tc39.github.io/ecma262/#sec-modules

Summary

ECMAScript 2015 (previously known as "ES6", now usually shortened as "ES2015") defines a syntax for modular JavaScript programs, allowing one module to import symbols from another module which exports them. With <script type="module">, the HTML specification describes how such modules (and their imports) load on the web, as well as how they interact with the rest of the HTML processing model.

Due to the cross-cutting nature of the feature, implementation work will involve changes in both Blink and V8. In particular, a good amount of the interesting design work will be in the V8 API layer. The implementation work itself will help clarify exactly how Blink and V8 will work together to make modules operate in the browser.

Motivation

Modules in JavaScript have been a much-sought-after feature for many years. While ES2015 described the syntax and linking semantics, it left loading up to the host environment (in Chromium's case, the "host environment" is Blink). <script type="module"> encompasses all pieces of ES Loader "Milestone 0" (the hosting repo is where a separate loader spec is being developed), and as such is a first step towards supporting a full-featured JavaScript module system in Chromium.

JavaScript developers are currently making extensive use of the ES2015 syntax, but today that code must be handled by a pre-processor which converts it to use an existing module loading library before being loaded in a browser. <script type="module"> will enable such code to run directly in the browser, using standard URL resolution semantics for a module's imports.

Interoperability and Compatibility Risk

<script type="module"> is not currently supported in any shipping browser. The pull request for its addition to the HTML spec received and incorporated feedback from developers working on WebKit/JSC and Gecko/SpiderMonkey. Browsers will likely begin implementing it over the course of this year (Mozilla is already implementing).

ECMAScript Modules have some overlap with the features currently supported by HTML Imports (<link rel="import">): they both provide a framework for splitting a web app into discrete pieces. The interaction between <script type="module"> and <link rel="import">, in this round of implementation, will be similar to the way <script type="defer"> operates today in an HTML Import. The likely future shape of HTML Import/ES Module integration can be seen in the draft HTML Modules proposal, which aims to explain not only how ES modules can be loaded from HTML, but how HTML could be loaded from script.

Ongoing technical constraints

None.

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

Yes.

Launch tracking bug

https://bugs.chromium.org/p/v8/issues/detail?id=1569

Link to entry on the feature dashboard

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

Requesting approval to ship?

No.

[Domenic Denicola]

Yay! Super-excited to see this, Adam.

From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of Adam Klein

> The https://github.com/whatwg/html/pull/443 for its addition to the HTML spec received and incorporated feedback from developers working on WebKit/JSC and Gecko/SpiderMonkey.

And Edge/Chakra, who drove the related module worker design! They've also begun implementation, at least on the Chakra side: https://github.com/Microsoft/ChakraCore/pull/293 and https://github.com/Microsoft/ChakraCore/pull/457.

[Jochen Eisinger]

Very excited to see this happening!

I guess that's more of a question for the spec, but it looks like that there's no way for the preload scanner to start loading dependencies of a module before it is fully loaded, parsed, and executed, right?

[Adam Klein]

On Wed, Mar 9, 2016 at 10:58 PM, Jochen Eisinger <joc...@chromium.org> wrote:

Very excited to see this happening!

I guess that's more of a question for the spec, but it looks like that there's no way for the preload scanner to start loading dependencies of a module before it is fully loaded, parsed, and executed, right?

I don't think there's anything that should stop us from preloading. I'd actually expect this might be added as a callback from V8, to avoid having to teach Blink JS syntax, but the module specifiers are completely pre-parseable: there's no need to execute any code to determine what URLs they refer to.

[Jochen Eisinger]

ah, I see, so all module specifiers have to be string literals. That's good to see.

[oden...@gmail.com]

Any news? It's been quite a while. I'm still using system.js with a babel transform *only* used for modules. Still.  Unfortunately, the two of us in our business using modules are facing pretty heavy pressure from the rest of the team.

It seems to me the `<script>` approach was a good idea for a first landing of modules. But I sorta hoped to see them before 8 months!

The two links are interesting, the "bug" link certainly shows a lot of activity.

But it'd be great to know just what the problems are: Bad spec (shared between TC39 and whatwig)? Too hard .. too many formats? Not really that important, use Rollup/Webpack?

Any info helpful, thanks.

   -- Owen

[Adam Klein]

A few updates, as it's been awhile since this initial message:

- As of https://chromium.googlesource.com/chromium/src/+/29950db4, <script type=module> is available behind the "Experimental Web Platform Features" flag in Chromium (and in Chrome Canary as soon as this change makes it into a build)

- The Blink-side work is being led by kou...@chromium.org, and is tracked at https://bugs.chromium.org/p/chromium/issues/detail?id=594639

- The V8 implementation, tracked at https://bugs.chromium.org/p/v8/issues/detail?id=1569, is more-or-less complete

[PhistucK]

Will modules be supported in insecure contexts?

I vote for no.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Dominic Cooney]

I think the plan is to make modules available in insecure contexts.

I don't think modules pose particular special security risk beyond script, so while they're a new feature, they're not a "powerful" new feature in the security sense.

You could imagine trying to confuse the module map to provide an insecure script module to a different origin, but the design mitigates that by having the module map hang off the context as you can see here.

I believe there are (failing) WPT tests for crossorigin modules in external/wpt/html/semantics/scripting-1/the-script-element/module. I assume the plan is to fix them?

Kouhei, Domenic, are there tests for modules and CSP?

Dominic

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2B7QeKNmnSCYK6CbPPGZeY14rifhJmXwm-str6byRJ8rw%40mail.gmail.com.

[Kouhei Ueno]

On Wed, May 24, 2017 at 10:08 AM, Dominic Cooney <domi...@chromium.org> wrote:

I think the plan is to make modules available in insecure contexts.

I don't think modules pose particular special security risk beyond script, so while they're a new feature, they're not a "powerful" new feature in the security sense.

You could imagine trying to confuse the module map to provide an insecure script module to a different origin, but the design mitigates that by having the module map hang off the context as you can see here.

FYI: There is also an on-going discussion to ban exec of <script> element that moved between documents during fetching.

see https://github.com/whatwg/html/issues/2469

I believe there are (failing) WPT tests for crossorigin modules in external/wpt/html/semantics/scripting-1/the-script-element/module. I assume the plan is to fix them?

Tracked at https://bugs.chromium.org/p/chromium/issues/detail?id=717525 I believe

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHnmYQ9ER9g1_AKOpEW%2BK64nLcnJoeUkjTyA9F1K8m1tHZ98cQ%40mail.gmail.com.

--

kouhei

[PhistucK]

While it is not powerful in terms of security, but it is powerful in terms of usefulness. It could be a strong point do adopt HTTPS (or a strong point for HTTP not to use them, which probably makes sense anyway, because modules are really optimized for HTTP/2 anyway, for which browsers require HTTPS).

☆PhistucK

[Dominic Cooney]

On Wed, May 24, 2017 at 9:41 PM, PhistucK <phis...@gmail.com> wrote:

While it is not powerful in terms of security, but it is powerful in terms of usefulness.

That's true, but I think the idea about limiting powerful new features to secure origins is mostly about security. This is the impression I get from https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features https://www.w3.org/TR/secure-contexts/

 

It could be a strong point do adopt HTTPS (or a strong point for HTTP not to use them, which probably makes sense anyway, because modules are really optimized for HTTP/2 anyway, for which browsers require HTTPS).

Yeah, that's an interesting point.

On balance I think it is better to stick to the plan to just ship them to HTTP as well.