As has been discussed many times, TC39 doesn’t need to endorse Node placing host-environment-specific restrictions on its inputs. They already impose restriction that CJS modules be FunctionBody, instead of the top-level Script production in the spec. Similarly, they can create their own grammar production, ModuleWithRequiredImportOrExport (or whatever), and impose that on their users as a second alternate restriction.

What many people in TC39 will not support is placing an unnecessary restriction on all users of JavaScript. That is against the goal of our job as a host-environment-agnostic language. We supply the building blocks, and different host environments do different things with those. E.g. HTML has a nonstandard entry point for inline event handlers (onload=""), but we don’t codify that restriction into the language in some way; that’s just not our job and would be counterproductive to environments like Node which don’t need to support inline event handlers.

Furthermore, at least several members of TC39 see a file extension as a tried-and-true way of communication out of band metadata, and think that’s a fine way to go. There are other possibilities, e.g. using import for ES modules and require for CommonJS ones (along with a command-line switch for the entry module). So even if you’re talking about endorsing Node.js requiring ModuleWithRequiredImportOrExport for their users, I don’t think you’ll find a consensus among TC39 to “endorse” such an approach, since several members think it’s a less elegant solution than other possibilities.

From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of martin heidegger
Sent: Tuesday, September 6, 2016 23:17
To: es-discuss at mozilla.org
Subject: Endorse an unambiguous syntax for ES2015 modules

I would like to ask this again, in more depth than on twitter<https://twitter.com/leichtgewicht/status/773348056775266304> ...

The ES6 module support proposal of Node-eps currently states<https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md#51-determining-if-source-is-an-es-module>:

Note: While the ES2015 specification does not forbid<http://www.ecma-international.org/ecma-262/6.0/#sec-forbidden-extensions> this extension, Node wants to avoid acting as a rogue agent.
Node has a TC39 representative, @bmeck<https://github.com/bmeck>, to champion this proposal.
A specification change or at least an official endorsement of this Node proposal would be welcomed.
If a resolution is not possible, this proposal will fallback to the previous .mjs file extension proposal<https://github.com/nodejs/node-eps/blob/5dae5a537c2d56fbaf23aaf2ae9da15e74474021/002-es6-modules.md#51-determining-if-source-is-an-es-module>.

Unambiguous ES6 module support is imho<https://github.com/nodejs/node-eps/pull/39#issuecomment-245157827>:

... an embarrassingly simple solution that would fix a major problem by creating a little effort for a minority of users and makes everyone's life better.

... so: What is the problem for the TC39 to doing the endorse this effort?

best regards
Martin Heidegger

P.S.: I have noted in a write-up of the ES6 module for Node.js integration that this would be important http://es2015-node.js.org/#changing-the-es2015-specification
P.P.S.: Thanks to Matthew Phillips<https://twitter.com/matthewcp/status/773351980068638720> for pointing me to es-discuss.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160907/248aeb2a/attachment.html>

As has been discussed many times, TC39 doesn’t need to endorse Node placing host-environment-specific restrictions on its inputs. They already impose restriction that CJS modules be FunctionBody, instead of the top-level Script production in the spec. Similarly, they can create their own grammar production, ModuleWithRequiredImportOrExport (or whatever), and impose that on their users as a second alternate restriction.

What many people in TC39 will not support is placing an unnecessary restriction on all users of JavaScript. That is against the goal of our job as a host-environment-agnostic language. We supply the building blocks, and different host environments do different things with those. E.g. HTML has a nonstandard entry point for inline event handlers (onload=""), but we don’t codify that restriction into the language in some way; that’s just not our job and would be counterproductive to environments like Node which don’t need to support inline event handlers.

Furthermore, at least several members of TC39 see a file extension as a tried-and-true way of communication out of band metadata, and think that’s a fine way to go. There are other possibilities, e.g. using import for ES modules and require for CommonJS ones (along with a command-line switch for the entry module). So even if you’re talking about endorsing Node.js requiring ModuleWithRequiredImportOrExport for their users, I don’t think you’ll find a consensus among TC39 to “endorse” such an approach, since several members think it’s a less elegant solution than other possibilities.