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

[Kouhei Ueno]

Contact emails

{adamk, kouhei, hiroshige, neis}@chromium.org

PM: kenji...@chromium.org

Spec: {domenic, neis}@chromium.org

 

Spec

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

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

TAG review

 

Summary (from the intent to implement)

The JavaScript specification 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.

 

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/uba6pMr-jec/tXdg6YYPBAAJ

 

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

Yes.

 

Demo link

https://paulirish.github.io/es-modules-todomvc/

 

Debuggability

Baseline module support (module as script).

 

Out-of-scope features

Initially, the following aspect(s) will not be supported:

• <script type=module> in XHTML (crbug)

 

Interoperability and Compatibility Risk

Edge: In preview build

Firefox: Behind a flag

Safari: Shipped

Web developers: Positive

 

Is this feature fully tested by web-platform-tests?

Yes. Extensive contributions to web platform tests have been contributed by Edge, WebKit, Blink, and V8 engineers during spec and implementation development.

 

OWP launch tracking bug

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

 

Entry on the feature dashboard

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

[TAMURA, Kent]

Do other browsers support type=module in XHTML documents?

--
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/CAPVAxLUFAYjE7r2kK-6OSCG9DFDwTc0qNUEnw8cFsa%3D9UbVEKQ%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[Kouhei Ueno]

The other browser support status is as follows.

<script type=module> support in XHTML:

WebKit: no

Edge (preview build): yes

Firefox (behind a flag): yes

As hiroshige@ commented in the bug, supporting <script type=module> in XHTML document is non-trivial work in Chromium.

For the time being, we will make sure that the developers are notified of the situation in devtools console.

--

kouhei

[PhistucK]

On Wed, Jun 21, 2017 at 4:44 AM, Kouhei Ueno <kou...@chromium.org> wrote:

Is this feature fully tested by web-platform-tests?

Yes. Extensive contributions to web platform tests have been contributed by Edge, WebKit, Blink, and V8 engineers during spec and implementation development.

What about test-262 (web-platform-tests are not supposed to test ECMAScript features) for modules?​

Are all of the test-262 tests run on modules as well (at least those that do not require sloppy mode features, because if I remember correctly, modules always run in strict mode)?

​Also, how does this integrate with service workers? Is there a type or something that signals that the fetch event is for a module fetch?

☆PhistucK

[Domenic Denicola]

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

> What about test-262 (web-platform-tests are not supposed to test ECMAScript features) for modules?​

This is not an ECMAScript feature; this is an intent-to-ship specifically for <script type=module>, and HTML feature. As such test262 tests are out of scope.

There are some test262 tests for modules, but those are related to foundational work done by the V8 team earlier in the process, and not related to the work being done in this intent to ship.

> ​Also, how does this integrate with service workers? Is there a type or something that signals that the fetch event is for a module fetch?

<script type=module> is just another script. There is no special treatment for them in service workers or at the network layer.

(If you have further questions of this sort, perhaps ask them on the specification repo or StackOverflow; we should probably not get into a tutorial on the modules spec here.)

[Adam Klein]

On Wed, Jun 21, 2017 at 8:25 AM, Domenic Denicola <d...@domenic.me> wrote:

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

> What about test-262 (web-platform-tests are not supposed to test ECMAScript features) for modules?​

This is not an ECMAScript feature; this is an intent-to-ship specifically for <script type=module>, and HTML feature. As such test262 tests are out of scope.

There are some test262 tests for modules, but those are related to foundational work done by the V8 team earlier in the process, and not related to the work being done in this intent to ship.

That being said, V8 passes all but three of the test262 tests for modules (see https://cs.chromium.org/chromium/src/v8/test/test262/test262.status?rcl=ea49cd0a053b89c31013b98a4763b9c9c75fe07a&l=356), and those tests have to do with corner cases of object reflection on namespace objects, which is 1) minor and 2) completely orthogonal from module loading in HTML.

- Adam

[PhistucK]

Since there is no intent-to-ship-modules thread in V8 (and since this intent brings module support into HTML as well as scripts and not just one or the other), I think the test262 question is very much appropriate in this thread (you may disagree, but I may, too ;)).

☆PhistucK

[PhistucK]

Thank you! A few minor failures are not worrying, indeed. :)

Has anyone run the full test262 test suite within a module scope, just to make sure all of the ordinary features work there the same?

(I understand that from a point of view of an implementor, this might seem unnecessary, because it is the same engine, but who knows, it may uncover hidden peculiarities in the engine)

☆PhistucK

[PhistucK]

On Wed, Jun 21, 2017 at 6:25 PM, Domenic Denicola <d...@domenic.me> wrote:

<script type=module> is just another script. There is no special treatment for them in service workers or at the network layer.

​Yeah, at the moment, there no special treatment, but if https://github.com/whatwg/fetch/issues/486 (which you filed) adds more as types, I guess they might propagate to fetchEvent.request.type for service workers to have as well​. That sounds like good information to have in service workers, but, yes, off topic for this intent.

☆PhistucK

[Adam Klein]

On Wed, Jun 21, 2017 at 9:44 AM, PhistucK <phis...@gmail.com> wrote:

Has anyone run the full test262 test suite within a module scope, just to make sure all of the ordinary features work there the same?

(I understand that from a point of view of an implementor, this might seem unnecessary, because it is the same engine, but who knows, it may uncover hidden peculiarities in the engine)

I don't know if anyone has done such a thing, but test262 does already include metadata that allows tests to be run in strict mode, sloppy (non-strict) mode, or both; I could imagine it being extended to make it easy for test runners to run tests as modules as well. github.com/tc39/test262/issues would be the place to raise that feature request.

[Mark Miller]

https://github.com/tc39/test262/issues/1065

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

  Cheers,
  --MarkM

[PhistucK]

Since this (intent) is a big feature, I think it would be appropriate to run the entire suite in a module scope before it is shipped.

Do you think it would take a lot of work to do that?

☆PhistucK

[ne...@chromium.org]

I expect a significant number of tests will fail due to the different semantics, thus it would take a lot of time to evaluate the results.

[PhistucK]

Will it be a lot of effort to just run the tests and create a list of failures? I can go over a manageable part of them and see if something looks fishy.

☆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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a0cfab54-5c05-4c81-8a60-a735762922ce%40chromium.org.

[Adam Klein]

There's infrastucture work to be done to let the test262 test harness run tests as modules. Again, the test262 github is the right place to discuss that issue.

As for the matter of this "missing" coverage: in their V8 implementation, the code generated for modules simply isn't that different from the code generated for other JS code. So while this might be a nice sanity check to have in the fture, it's not something that I'd expect to actually provide much more value in the "code coverage" sense.

[Dimitri Glazkov]

LGTM

--
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/CAPVAxLUFAYjE7r2kK-6OSCG9DFDwTc0qNUEnw8cFsa%3D9UbVEKQ%40mail.gmail.com.

[Chris Harrelson]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx7vcOepL1uBsi0jx5nhLv5nZmmGH%3DcSfBoNqeu%3DDrAmtQ%40mail.gmail.com.

[Rick Byers]

LGTM3

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

[TAMURA, Kent]

LGTM4.

Usually we should avoid shipping an incomplete implementation. However it's ok in this case because it is interoperable with Safari, which already shipped type=module.

Because of the status of Edge and Firefox, we should implement type=module for XHTML documents ASAP.