Re: [blink-dev] Intent to Ship: <script type="module">

[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

[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

On Wed, Jun 21, 2017 at 9:07 PM, <ne...@chromium.org> wrote:

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.

--
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.