Endorse an unambiguous syntax for ES2015 modules

Jordan Harband ljharb at gmail.com
Wed Sep 28 22:39:54 UTC 2016


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 <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.
>
>
>
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160928/4e9965f1/attachment.html>


More information about the es-discuss mailing list