An alternative answer to "What is the problem for the TC39 to doing the endorse this effort?" is, it hasn't been presented to the committee yet. So, it's a little soon to declare that there is or is not a consensus, or that TC39 is doing or not doing anything about it. The committee hasn't been given the chance to consider it yet.
On Tue, Sep 6, 2016 at 8:24 PM, Domenic Denicola <[email protected]> wrote: > 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 > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
