Thank you for taking the time to answer. For some reason it seems like I framed it to be a Node.js specific issue. In my understanding the current ES2015 module specification is ambiguous regarding backwards compatibility. Node.js or Browser that surely is an issue for the implementers?! This seems like a hole/bug/problem in the specification to me. (Please correct me if I am wrong). And it also seems to me like this is a serious issue.
This problem can be solved in my understanding either by adding out-of-band metadata (file extension, mime-type, ...) or within the file ( shebang like comments, "use strict" like spec etc.). > since several members think it’s a less elegant solution than other > possibilities. Considering the other options I - with a lot of effort [1] - can not think of a better, cleaner solution for the ecosystem. You write that "several members" think otherwise: I hope it an agreement for the best way to fix that can be found and that agreement is used as endorsement (or not) for implementing the logic in Node.js. It would be important to know if they work into the right direction. best regards Martin Heidegger [1] I wrote this: https://github.com/martinheidegger/es6modules-nodejs On 7 September 2016 at 12:24, 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
