Endorse an unambiguous syntax for ES2015 modules

martin heidegger martin.heidegger at gmail.com
Thu Sep 29 07:25:20 UTC 2016


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 <d at domenic.me> 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: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/20160929/b0647f2a/attachment-0001.html>


More information about the es-discuss mailing list