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:[email protected]] On Behalf Of martin heidegger Sent: Tuesday, September 6, 2016 23:17 To: [email protected] 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.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
