Test modules again

[fflorent]

Issue #240 has removed the module tests from the table. They should eventually be back, right? :)

Florent

[dead-claudia]

Yes, they should.

Actually, part of the problem was that, until recently, most of the module semantics itself was in flux. Traceur was changing parsing and some of its internals very frequently during that time, and no sane implementor (transpilers excluded) is going to implement a continuously changing part of any spec, no matter how progressive they are (Blink and SpiderMonkey tend to be eager to implement experimental features, but nobody has actually implemented it).

Now, it is relatively stable, and many more people are starting to prefer them to CommonJS's require() and AMD's define()/require(). Currently, though, given the SystemJS loader and the vast amount of the easier, still very interesting, things to implement, engine developers aren't likely to implement this quite yet (hopefully soon, though).

[webbedspace]

There are two large (but not insurmountable) problems with testing modules:

1. Modules are async (same problem with testing Promise)
2. Modules require a <script type="module"> tag - testing support for this will require a different approach than just running code in a normal <script> tag.

[dead-claudia]

Actually, it appears that the module loader itself isn't quite specced out yet, and much of the specification work has been stalled by needed work in other areas, especially the ECMAScript version 6 specification draft. I would suggest that it should be closed for now, until there is actually much of a specification to implement.

One thing I did notice is that the loader spec, even though it is hosted by WHATWG, is being written with Node.js in mind, potentially as an implementer itself. That opens up a lot of possibilities.

[kangax]

@webbedspace according to http://www.2ality.com/2014/09/es6-modules-final.html we can't use eval

[fflorent]

Sorry for the delay of the answer.

1. Modules are async (same problem with testing Promise)

Oh! Why is that a problem?

@webbedspace according to http://www.2ality.com/2014/09/es6-modules-final.html we can't use eval

If I understand well, the idea of using eval is to avoid errors (and especially syntax errors) preventing the other tests to run, right? So what about putting the test in an iframe? If I am not wrong, a JS error in an iframe doesn't stop the execution of the scripts in the parent windows?

Florent

[dead-claudia]

Testing a Promise shouldn't be nearly that big of a deal, nor should loading itself. The bigger stumbling block is that the loader spec is still in active development, and isn't even complete enough to implement pieces of yet. Parsing support is the most you could possibly test, and even that is, AFAICT, impossible to test in a browser environment because of the ES6 spec and existing, stable HTML5 spec.

Here's what is realistically required to test for module support in a web browser environment, with specification status below each one:

1. An element dedicated for modules.

The most likely syntax I seem to be hearing at this point is simply using the traditional import syntax with a loader for importing other modules (i.e. no extra elements have to be added) and this for immediately loaded and executed modules:

<script type="module">
import foo from 'bar.js';
console.log(foo);
</script>
<script type="module" src="foo.js"></script>

The larger issue is that of "do HTML implementors implement this?", since it requires these semantics to be properly recognized and parsed. 2. A consistent loader API for loading and manipulating modules from regular <script> elements and dynamic loading of modules from other modules, as opposed to static module imports. This appears to be where the loader API stands at the moment, based on the ES6-turned-WHATWG loader specification. It targets both server-side and browser implementors. Many parts are just an educated guess based on the previous version in the ES6 specification.

// Dynamic import
System.import(name: string, options: object) -> Promise

// Load, but do not evaluate
System.load(name: string, options: object) -> Promise

// Alias an import to its source (I think...just an inference)
System.provide(name: string, src: string) -> undefined

// Hook to affect how paths are normalized
System.hook(
  "normalize",
  normalize: (name: string, referrer: string, address: string) -> string
) -> undefined

// Hook to affect how modules are located
System.hook(
  "locate",
  locate: (loadRequest: Object) -> Object
) -> undefined

// Hook to affect how modules are fetched
System.hook(
  "fetch",
  fetch: (loadRequest: Object) -> string
) -> undefined

// Hook to translate/compile source code after being fetched, but before
// fully loaded, such as compiling CoffeeScript files. Similar to Node's
// deprecated (but unremovable - the API is locked) require.extensions.
System.hook(
  "translate",
  translate: (loadRequest: Object) -> string
) -> undefined

// Hook to support importing pre-ES6 modules, such as CommonJS or AMD
System.hook(
  "instantiate",
  instantiate: (loadRequest: Object) -> Object
) -> undefined

// Respective getters for each
System.hook("normalize")
System.hook("locate")
System.hook("fetch")
System.hook("translate")
System.hook("instantiate")

// A (string, module) map serving as a cache, to avoid repeat loads.
// Similar to the require.cache object in Node.js
System.modules: Map

Note that the inner workings are largely under development currently, anyways. No implementation exists yet, although the previous version that was in the spec was already polyfilled at this point. The most popular one, es6-module-loader, has begun to stall a little after the loader was removed from the ES6 specification draft. 3. A way to dynamically load a module. In the browser, you can dynamically create <script type="module">, which should be easy to do with an enclosing <iframe>. That would test browser recognition of the syntax.

function testModule(src, expected, cb) {
  'use strict';

  var waiting = true;
  var failedParse = false;
  var answerFailed = false;
  var i = 0;
  var timer;
  var cache = {};

  function ret(str, reason) {
    if (!(reason in cache)) {
      cache[reason] = false;
      cb(str == null ? str : new Error(str), reason);
    }
  }

  var iframe = $('#test-iframe');
  var iframeWindow = iframe.attr('contentWindow');

  iframeWindow.resolve = function (val) {
    if (val !== expected) {
      ret('Expected: ' + expected + ', Found: ' + val, 'value');
    } else {
      ret(null, 'resolved');
    }
  };

  var script = $('<script>')
    .attr('type', 'module')
    .attr('text', src
      .replace('\x3c!--', '\\x3c!--')
      .replace('\x3cscript', '\\x3cscript'));

  iframeWindow.onerror = function (msg) {
    ret(msg, 'error');
  };

  iframe.empty().after(script);
}

In Node, it would be far simpler except for the required temp file and asynchronous event loop work surrounded by a try-catch to ensure it doesn't kill the program. It's otherwise as simple as child_process.fork(). It should be similar for other server-side JavaScript implementations.

function testModule(src, expected, cb) {
  'use strict';
  var fs = require('fs');

  var tmpfile = './tmp.js'; // or whatever works best
  var called = false;
  var cache = {};

  function Wrapper(err) {
    this.err = err;
  }

  function ret(err, reason) {
    if (called === false) {
      cache[reason] = called = true;
      fs.unlink(tmpfile, function (unlinkErr) {
        if (unlinkErr) {
          throw new Wrapper(unlinkErr);
        } else {
          cb(err, reason);
        }
      });
    } else if (!(reason in cache)) {
      cb(err, reason);
    }
  }

  fs.writeFileSync(tmpfile, 'utf8', src +
    ';function resolve(v){process.send(v)};');

  try {
    require('child_process').fork(tmpfile)
    .on('message', function (val) {
      if (val !== expected) {
        cb(new Error('Expected: ' + expected + ', Found: ' + val), 'value');
      } else {
        cb(null, 'resolved');
      }
    })
    .on('error', function (err) {
      cb(err, 'error');
    });
  } catch (e) {
    if (e instanceof Wrapper) { // if the unlink failed
      throw e.err;
    } else {
      cb(e, 'error');
    }
  }
}

These implementations are self-contained here, but can be edited to be less so. Make sure to call resolve(returnVal) to return the value to the parent if you use this, and the callback is called with two arguments: the error, if it exists, and the resolution reason, one of 'error' for an error in loading the script, 'value' for an incorrect value, and 'resolved' for a verifiably correct value.

I know this is quite a hack, and relies on some very platform-dependent behavior, but something like this should suffice to test modules, once the specification stabilizes. But, as it stands now, the loader itself is far too immature to reliably test much of anything.

[kangax]

As of now, I don't see a good way to test for modules support at all — http://es-discourse.com/t/how-is-module-code-and-global-code-differentiated/ We could try <script[type=module] or <module> for browsers but even that is uncertain at the moment, from what I understand, and for non-browsers it's unclear even more. Feels like shooting in the dark.

[dead-claudia]

I agree. I would suggest closing this for now, and opening a new one once there's a stable enough standard to actually test against. Also, such tests would, by necessity, have to be somewhat platform-specific.

And WRT Node, there doesn't even exist any solution AFAIK outside of es6-module-loader and friends.

[kangax]

V8 folks are already working on modules — https://code.google.com/p/v8/issues/detail?id=1569#c7 — so we'll have at least few implementations to test soon (Traceur, 6to5, V8)

[dead-claudia]

Module parsing is irrelevant without a full loader, though. The issue and CL are a WIP for parsing support. On Jan 28, 2015 3:52 PM, "Juriy Zaytsev" [email protected] wrote:

V8 folks are already working on modules — https://code.google.com/p/v8/issues/detail?id=1569#c7 — so we'll have at least few implementations to test soon (Traceur, 6to5, V8)

— Reply to this email directly or view it on GitHub https://github.com/kangax/compat-table/issues/316#issuecomment-71913401.

[kangax]

This is what they already have — https://chromium.googlesource.com/v8/v8/+/f7dc15febeea78b22de1f57c397a3221a43d9213/test/mjsunit/harmony/module-linking.js

Only I'm not sure what that module R { ... } syntax is about. I don't see anything like this in latest ES6 spec.

[dead-claudia]

That was the old spec. Such a module literal was pulled at least six months ago. What they already have is known to be outdated. The current spec is being both reconstructed from old specifications, modernized, and generally developed here: http://whatwg.github.io/loader/ It is planned to become a living standard, but it isn't even developed far enough for that.

[probins]

I'd suggest adding a note on the web page somewhere explaining why modules aren't in the table even though they're part of the ES6 spec

[paulirish]

Agree, the es6 modules implementation story is of huge interest to folks right now.

[kangax]

I noticed V8 folks actively working on it lately so it looks like we'll be having browser implementations pretty soon. So far it's only compilers, as far as I know (babel, traceur).

[dead-claudia]

I don't think they are going to do much on the module linking side, though. On Feb 28, 2015 5:24 PM, "Juriy Zaytsev" [email protected] wrote:

I noticed V8 folks actively working on it lately so it looks like we'll be having browser implementations pretty soon. So far it's only compilers, as far as I know (babel, traceur).

— Reply to this email directly or view it on GitHub https://github.com/kangax/compat-table/issues/316#issuecomment-76552005.

[probins]

the loader is a separate story. As it's no longer part of the ES spec, it doesn't really belong here, and ISTM it would be better on the caniuse site. Having said that, support for module parsing isn't much use without a loader, so the two are closely intertwined. A new version of the polyfill based on the new spec has just been published https://github.com/ModuleLoader/es6-module-loader/tree/1.0/src but I too doubt whether anyone will start work on any implementations until the spec is more advanced - at the moment, there are still a lot of todos.

[silverwind]

As for testing syntax support on the server, I found this simple method:

$ babel-node -e 'process.on("uncaughtException", function(){console.log("modules supported")}); import a from "b.js"'
modules supported

In case of no support, it errors:

$ iojs -e 'process.on("uncaughtException", function(){console.log("modules supported")}); import a from "b.js"'
[eval]:1
"uncaughtException", function(){console.log("modules supported")}); import a f
                                                                    ^^^^^^
SyntaxError: Unexpected reserved word

One might run that in a vm instance to possibly catch that SyntaxError.

[dead-claudia]

+1 for that idea (WRT Node/etc.) On Apr 16, 2015 15:02, "silverwind" [email protected] wrote:

As for testing syntax support on the server, I found this simple method:

$ babel-node -e 'process.on("uncaughtException", function(){console.log("modules supported")}); import a from "b.js"' modules supported

In case of no support, it errors:

$ iojs -e 'process.on("uncaughtException", function(){console.log("modules supported")}); import a from "b.js"' [eval]:1"uncaughtException", function(){console.log("modules supported")}); import a f ^^^^^^ SyntaxError: Unexpected reserved word``

— Reply to this email directly or view it on GitHub https://github.com/kangax/compat-table/issues/316#issuecomment-93815908.

[backspaces]

Hope this isn't too noob, but why not just test for the existence of window.System, and its few well-known functions. The compat-table site is clear:

Please note that some of these tests represent existence, not functionality or full conformance

Axel Rauschmayer, in http://www.2ality.com/2014/09/es6-modules-final.html, says in the comments:

You could check for System and System.module() (and possibly even call the latter).

[kangax]

I think System was removed at some point (possibly with intention to move it to loader API but last time I checked it wasn't there — please correct me if I'm wrong)

Sent from my iPhone

On 23 May 2015, at 13:05, Owen Densmore [email protected] wrote:

Hope this isn't too noob, but why not just test for the existence of window.System, and its few well-known functions. The compat-table site is clear:

Please note that some of these tests represent existence, not functionality or full conformance Axel Rauschmayer, in http://www.2ality.com/2014/09/es6-modules-final.html, says in the comments:

You could check for System and System.module() (and possibly even call the latter). — Reply to this email directly or view it on GitHub.

[silverwind]

Yeah, no System or Reflect.Loader available in latest Babel. Why is this so damn hard to test for :cry:

[dead-claudia]

Because the Web loader needs a spec to be worth anything. Server side runtimes can come up with their own loader for now. And the module resolution and loading itself is almost completely implementation-defined as per the spec. The first engine to likely be using ES6 module syntax will likely be io.js, since V8 has gotten the farthest on its implementation of the current syntax (and it already has numerous unit tests for it). SpiderMonkey has parsing support for the old syntax, but the buggy let/const support is blocking progress on it.

(Aside: It's unsurprising that V8 is the farthest along, considering it's the backend for Node and io.js, among several other CLI runtimes, and it's frequently embedded in other applications as well.)

[dead-claudia]

And @kangax, yes, it was, and that's the reason. Their goal is to standardize a promise-based module API across the server and client. Thing is, the initial draft is still a WIP, and the work is largely currently overshadowed by the ES6 implementation work, along with a possible errata for a few spec bugs.

Thankfully, the ES7 proposals are relatively small comparatively, in that they can be easily polyfilled/transpiled or implemented, with the most complicated part being async generators. (The rest can simply be desugared or implemented in plain ES6 in engines, including async functions, decorators, static properties, and the on operator. Object.observe and its Array counterpart are impossible in pure JS, but extremely easy on the implementer's side.)

[mc-suchecki]

For everyone that ended up here while checking the status on ES6 Modules implementation on various browsers, here is an useful link: https://www.chromestatus.com/features/5365692190687232 Sadly, there isn't much going on in that matter so far.

Also, +1!

[paulirish]

@mc-suchecki there's a new and very active conversation to get a loader into the html spec: https://github.com/whatwg/html/pull/443

[mc-suchecki]

Thank you @paulirish, I will look into it. :+1:

[paulirish]

It's now merged into the spec: https://html.spec.whatwg.org/multipage/scripting.html#script https://twitter.com/domenic/status/689897197308092416

[flying-sheep]

Is there any reason why there isn’t at least a basic test for the syntax available?

This would help people see at a glance that this feature is the last one not even partly implemented by the big browsers.

[probins]

AIUI all the main browsers have partly implemented module support. They started with parsing of import/export, and are now looking into implementing <script type="module">. The announcement from Chromium/Blink team is a good summary.

[flying-sheep]

well, i mean in a shipped version. surely the implementation of e.g. the syntax is there but turned off, right?

[probins]

it's implemented in the JS engines and exposed in the shell, for example, in SpiderMonkey you can do parseModule(). But that isn't and won't be exposed in the browser, as it isn't useful without a loading mechanism, just as parsing a script tag isn't useful without resolving/fetching/caching/etc, which all goes on in the background. So I'm not sure that there's anything that this repo/table can test. The basic issue is that import/export aren't like the other language features. They are not useful on their own, but only as part of a much bigger process for analysing, loading and executing the whole dependency tree. Even if there were a test for parsing import/export, this wouldn't tell you much, as the important test is whether the bits of code you want are loaded and executed correctly with all the exports exposed as appropriate. Once browsers start releasing <script type="module"> then you can test that, but I'm not sure that belongs here, as it's html not ES6.

[flying-sheep]

well, obviously there is interest, so we should continue to think about how to test it.

the spec says:

Every host environment must implement a default loader object as the initial value of the loader property of the System object.

System.loader Object

The Default Browser Loader Object is an %BrowserLoader% instance, whose internal slots are set as if it had been constructed by the expression Construct(%BrowserLoader%).

idk why it says “Every host environment” and then continues to talk about browsers as if node etc. didn’t exist. still, maybe we can

1. test if System and its well known methods exists
2. call System.register to register a function and run a script which uses the import syntax to import that function and then call it

[probins]

System is not part of ES6, and only defined in the loader spec. That won't be implemented until the spec is finalised.

[flying-sheep]

ah, got it. so we can basically only test if export works by letting the JS engine parse a module…?

or is import guaranteed to throw some kind of import error if nothing is registered (instead of a syntax error) and we can test that?

[dead-claudia]

I'm pretty sure <script type="module"> is the only real way to test this, and we're still waiting on the Loader spec for anything meaningful outside Node itself, where a few people are working separately on ES6 and CommonJS interop, using the current system.

On Tue, Apr 12, 2016, 07:24 Philipp A. [email protected] wrote:

ah, got it. so we can basically only test if export works by letting the JS engine parse a module…?

or is import guaranteed to throw some kind of import error instead of a syntax error and we can test that?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/kangax/compat-table/issues/316#issuecomment-208854599

[lobo-tuerto]

I hope this is the year of ES2015 modules! :)

[Mouvedia]

System is not part of ES6, and only defined in the loader spec. That won't be implemented until the spec is finalised.

@probins that's what the esnext table is for, right?

[probins]

no, that's for future developments of ES/JS. The specs for loading modules are separate from the language itself, and being worked on in WHATWG.

[backspaces]

The specs for loading modules are separate from the language itself

​There lies the problem: ​

​Standards are hard enough. Split standards are impossible.

and being worked on in WHATWG

​ And very, very slowly.

I don't want to disrespect the process, but I hope this split never happens again. And it is going to make node lag behind es6, creating yet another problem for modules.

​If TC39 had complete control over the module spec, modules would already be in the browser just as the rest of es6 is. And node would inherit them via the V8 engine.​

[probins]

If TC39 had complete control over the module spec, modules would already be in the browser just as the rest of es6 is.

if module loading was still in ES2015, we'd still be waiting for ES2015 to be finalised :-)

[cen1]

Something really should be done about this issue because right now, the table makes you think that ES6 is fully supported by some browsers even though it's not. import/export syntax is one of these big missing features. It is being used already a lot in production with the help of browserify. I tested a script tag with an import, Chrome returns "Unexpected token import" while Firefox returns "SyntaxError: import declarations may only appear at top level of a module". If import syntax is used inside a <script type="module">, Chrome throws the same error while Firefox passes with no errors which is a basically a lie. This is obviously not a good test then. Edge throws a syntax error. At least a manual entry should be added to the table to show that modules as a whole are not atually supported by anything.

[Mouvedia]

Check whatwg/loader#147 for things to come. tl;dr: try…catch import() or typeof self.import in a script tag of type module

[probins]

@cen1 module scripts should work in Edge with experimental JS enabled https://blogs.windows.com/msedgedev/2016/05/17/es6-modules-and-beyond/ See https://bugzilla.mozilla.org/show_bug.cgi?id=1240072 for status with Firefox. Blink/V8 support is in progress https://bugs.chromium.org/p/chromium/issues/detail?id=594639

[backspaces]

Interesting that using browserify to convert to commonJS works .. but I think still needs babel to convert the import/export to commonJS? The transpilation can be only for module import/export, thus using the browser's es6 capabilities, which is nice.

My approach has been to use babel to only transpile modules, to system.js, then have a single use of system.import in the web page, which kicks off the transitive closure of module import/export conversion. Uses: babel-plugin-transform-es2015-modules-systemjs

Unfortunately, our assumption was that that stunt would be unnecessary for long. That was in April. Sigh. We'd love to pull babel out of the loop.

[cen1]

@backspaces true, I believe babel is needed (babelify).

[kangax]

I think manual entry would make sense at this point. Can someone make a PR?

@ljharb @webbedspace @zloirock no objections?

[zloirock]

Makes sense.

[ljharb]

I still don't think we should add it or mention modules at all outside of a note at the top. The loader spec is not finished, and if this table indicates import/export support as missing, then that will encourage implementors to ship module support while it's still half-baked.

[cen1]

Tested latest Edge build and modules do indeed seem to work, except default export failed (https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7657926/ is marked as fixed but not yet shipped apparently). One difference in syntax that I noticed in comparison to my babelify-ed code is that you need to add a .js to the from string location.

Even a mention/notice about modules would be better than nothing, at least then you know such thing exists. Now there is kinda-working implementation out there so it's a progress.

[probins]

the module specifier in <script type="module"> is a url, just as it is with standard scripts https://html.spec.whatwg.org/multipage/webappapis.html#resolve-a-module-specifier

[ljharb]

@probins yes, but node interop and thus what "all of npm will do" is still undetermined.

[indolering]

if this table indicates import/export support as missing, then that will encourage implementors to ship module support while it's still half-baked.

I thought everyone had switched to hiding partial implementations behind a runtime flag? This is probably the most important ES6 feature, and the last remaining one to be implemented. This would put healthy pressure on its development and a manual entry would take less time than has been spent arguing about it.

[paulirish]

I still don't think we should add it or mention modules at all outside of a note at the top. The loader spec is not finished, and if this table indicates import/export support as missing, then that will encourage implementors to ship module support while it's still half-baked.

I disagree with this. The onus is not on the compat-table project to wait for the standards process to finish on a feature before it's included. The visibility here will drive forward all aspects of shipping features. As you know, between tc39 and whatwg/w3c, there are plenty of practices put in place to assure that half-baked implementations are not shipped live without a flag.

I don't know about others, but I'd be much happier if implementors put even 1/4th of the time that's been dedicated to tail calls into modules. For better or worse, the presence in compat-table really influences this.

[webxl]

@kangax I can make a PR (if that call was directed to the public ;). I was going to leave the old test in there since all the others have something and stick "modules" under Syntax. Or leave the exec blank?

Any footnote necessary?

[ljharb]

@paulirish tail calls are a different scenario - they were fully standardized, and the discussion has been about implementation difficulty.

If you are asserting that Chrome will not ship an unflagged <script type="module"> and/or import/export support until the loader spec is finalized, then I will be happy to include modules in the compat table - but my current impression is that browsers currently plan, in fact, to ship module support (unflagged) before they should be.

[probins]

<script type="module"> implementation represents 'milestone 0', 'Basic static loading', of the loader spec roadmap. AIUI the intention was/is that these milestones could and should be implemented incrementally by browsers. I agree there are still open questions wrt the other milestones, including Node interop, but that surely should not be a reason for delaying implemention of milestone 0.

As for this table, its main purpose is surely to provide people with information. Modules are the biggest change there's ever been to the language - and this table has nothing to say on the subject?

[flying-sheep]

As for this table, its main purpose is surely to provide people with information. Modules are the biggest change there's ever been to the language - and this table has nothing to say on the subject?

yes, this is my issue with that as well. news outlets touting “chrome has 100% ES6 compatibility” disregarding the fact that this is pretty much impossible.

[backspaces]

This doesn't help node. Our goal is to unify node/browser JS, right? Presumably the v8 engine will help node to have import/export and that should be available to node.

[chicoxyzzy]

modules are behind a flag in Edge 14 now https://developer.microsoft.com/en-us/microsoft-edge/platform/status/moduleses6/

[indolering]

tail calls are a different scenario - they were fully standardized, and the discussion has been about implementation difficulty.

How is this different from ES6 modules? It's as "final" a standard as any web standard:

• The syntax was hammered out two years ago.
• The official ECMAScript standard was published in June 2015.
• Edge has already added preliminary support.
• The other three major engines are actively working on supporting it.

Why are we allowing ourselves to get hung up the dynamic loader? Wasn't it left out of the initial module spec to allow implementors time to experiment?

@webxl I for one would like to see a PR and there appears to be near-consensus that this should be included in the table.

[ljharb]

@indolering it's different because "tail calls" are in the spec. "ES modules", however, are not - what is in the spec is "import/export syntax", and "the module parse goal", but the concept of "ES modules" also includes "how to load a module", and that's not in the spec yet. We're not getting hung up on the dynamic loader, but rather all loading of any kind, without which, modules do not exist.

[indolering]

@ljharb From my reading of this loader ticket, "Milestone 0" signifies support for basic loading and execution of ES6 modules. Even if browsers can't currently fetch a module, could they parse and execute modules loaded through some other module loader?

I think it's clear that we need to list this somewhere. What if we moved into ESNext and used subfields to detail loader support?

[ljharb]

@indolering they certainly could, but there doesn't yet exist an engine that can that I'm aware of.

I think what would make the most sense is an entirely separate tab for modules - there's likely to be spec changes for them anyways, and we'll want to cover browsers, node, interop between scripts and modules, etc. That said, I don't think it's time yet for that information to be displayed anywhere.

[domenic]

Agreed with @ljharb, it's impossible to test the parts of modules that are in the spec in any kind of ES table. Maybe a separate page that combines the HTML specs and the ES specs, but modules are not in any interesting sense part of ES2015/2016/2017/....

It's also important to realize that the loader repo is a collection of interesting ideas from a few people, not a spec that has cross-browser agreement or support. See https://github.com/whatwg/loader/pull/152

[domenic]

Even if browsers can't currently fetch a module, could they parse and execute modules loaded through some other module loader?

They could. However, that is not required for being compliant with ES2015. It is 100% compliant with ES2015 to never parse modules at all. All that means is that the section of the spec for the module parse goal is never initiated in your engine. That's totally fine! There's no spec requirement that the Module goal ever be used. The spec just contains rules that apply if the Module parse goal is reached.

In other words, writing dead code that is never triggered does not make your engine more or less ES2015-complaint. Spec compliance deals with observable behaviors only, not the spec's internal algorithms, and from the ES2015 spec, module support is simply not observable. That's why it's accurate to say that modules are not in any interesting sense part of ES2015.

[indolering]

Thanks @domenic!

[flying-sheep]

to elaborate: if you execute an import statement in firefox’ console or scratchpad, you’ll get

SyntaxError: import declarations may only appear at top level of a module

which (unless you parse the error message) is indistinguishable from an engine not supporting the import syntax.

---

so we could test for basic support by checking if the syntax error message differs from other messages (an engine without import syntax support would say e.g. SyntaxError: unexpected token “import” at 1:1)

[ljharb]

@flying-sheep that would be testing something that's not in the spec.

[ghost]

I for one would like to see a PR and there appears to be near-consensus that this should be included in the table.

Agreed. Not mentioning ES6 Modules in the table is almost as good as suggesting they don't exist.

[ljharb]

They don't, yet. https://github.com/kangax/compat-table/issues/316#issuecomment-252176144

[gavinaiken]

But the "next" tab of the table includes all the TC39 proposals down to Stage 0, and the whatwg/loader collection of ideas is surely at least as far along as things at that stage, since it has been implemented in Edge and Safari and is under development in Firefox and Chrome? So I don't understand why you'd want to include those far-off language features but not modules?

[ljharb]

@gavinaiken Modules aren't part of the language spec; only most of the building blocks for them are.

Per https://github.com/kangax/compat-table/issues/316#issuecomment-252405375, a separate tab for Modules might make sense now that there begins to be engines shipping them; but it'd have to only test what was in the spec; using engine-specific (untested) means to get to the Module parsing goal.

[gavinaiken]

Is that not possible? Sounds like it would be worth it if it is.

[ljharb]

It's possible, but wouldn't be particularly fruitful at this time; although it would lay useful building blocks for the future. A PR to add a Modules tab would be interesting to review - but nobody's submitted one in the 5 months since I suggested it ¯\_(ツ)_/¯

[domenic]

the whatwg/loader collection of ideas is surely at least as far along as things at that stage, since it has been implemented in Edge and Safari and is under development in Firefox and Chrome?

That's not correct: https://github.com/whatwg/loader#implementation-status

none of them have begun work on the ideas prototyped here, since they are not ready for implementations yet.

[gavinaiken]

@domenic thanks for the correction, I did not realise that the whatwg/loader spec (or collection of ideas, whatever) was different from the browser implementation of <script type="module"> loading. Are the browser guys just making it up as they go along? Is there a spec they are working to? Can that be tested?

Re @ljharb's comment above about a PR to add a Modules tab, maybe the reason no one has submitted one yet is that they don't really understand the fine distinctions you folks on the committees have spent so long hammering out, so wouldn't know how to test what is agreed spec and what is still under discussion. I know I don't understand them well enough to attempt it...

[gavinaiken]

ps not meant to be a critical comment. Just a plea for more information and explanation really. Maybe a follow-up to https://blog.whatwg.org/js-modules ?

[domenic]

The spec for the script element is at https://html.spec.whatwg.org/multipage/scripting.html#the-script-element (as mentioned in that blog post)

[ghost]

To quote @paulirish earlier in the thread:

The onus is not on the compat-table project to wait for the standards process to finish on a feature before it's included. The visibility here will drive forward all aspects of shipping features. [....] For better or worse, the presence in compat-table really influences this.

Would it be acceptable to add a few failing tests to get the section back, or is this a Catch-22?

[ljharb]

@jhabdas per many comments in the above thread, the section does not belong on the ES2015 page. https://github.com/kangax/compat-table/issues/316#issuecomment-252405375 is the way forward.

[indolering]

@jhabdas per many comments in the above thread, the section does not belong on the ES2015 page. #316 (comment) is the way forward.

I'm in total agreement, support from Node is still at least a year away. It's clearly very complicated and might require changes to the spec.

Let's create a new modules tab and go from there.

[ghost]

@indolering @ljharb TBH I have no idea what "creating a tab" means, nor am I particularly interested in finding out. My intentions here are to drive module spec forward by raising visibility and need. And it's for that reason I added a PR the import() tests yesterday. Thank you.

[indolering]

@jhabdas We need an entirely new tab to track modules.

[ghost]

@jhabdas We need an entirely new tab to track modules.

Please see https://github.com/kangax/compat-table/issues/316#issuecomment-287592338

[ljharb]

@jhabdas presence of modules in the compat table will, at best, persuade implementations to implement (something that is not necessary; they are all implementing it), but at worst, persuade them to rush the implementation.

If you are not willing to "find out" or help create a new tab, then I'm afraid there's nothing you can do here to drive anything forward. Thanks for your comments.

[ghost]

@ljharb I'm sorry if the table is not structured properly at current. I tried to help by adding dynamic import tests and you closed the PR because you want a tab first when per spec there's benefit for both classic and module scripts. It's not my MO to put the carriage in front of the horse. I usually drive a car.

[ljharb]

As explained, the spec for import and import() can't be tested without environment-specific methods - the parsing goal is irrelevant there. The table is structured properly, which is why module tests don't appear anywhere. I'm not sure I get your metaphor, but if you want module tests on this table, please either help create a tab, or else there's no point in adding further noise to this thread.

If the tone of this thread continues to be problematic, I will lock it.

[indolering]

Here's a Modules Tab ticket, please bikeshed there!

If the tone of this thread continues to be problematic, I will lock it.

Do it, this is a good tombstone and I'm tired of it spamming up my notification feed.