Endorse an unambiguous syntax for ES2015 modules

Domenic Denicola d at domenic.me
Thu Sep 29 01:17:01 UTC 2016

From: martin heidegger [mailto:martin.heidegger at gmail.com] 

> 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 is not correct. There is nothing backward-incompatible about adding a new top-level grammar goal. And the new grammar goal has even less impact on Node.js, which does not use the existing grammar goal that the spec gives them (Script).

It's true that there are source strings that match both the Script and Module goals. But this is not a problem for backward-compatibility, and calling it "ambiguous" is a stretch. (Is the string "Hello, world!" a text/plain or text/html file? It's "ambiguous", I guess, but no known software has problems with this "ambiguity".)

So the specific proposal of "unambiguous module grammar" is very much a Node.js specific issue. It's even worse than that: it's a Node.js specific issue where the proposal is to turn that Node.js specific issue into a restriction placed on all host environments, not just Node.js.

> 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.).

Yes, exactly. Browsers have chosen to solve this with out-of-band metadata (`import` only works on modules, not scripts, and `<script type="module">` is there for the entry module). Node.js could do a similar solution (`import` only works on ES modules, not CJS modules, and `node --module` is there for the entry module). Or with a different out-of-band solution (such as .mjs). Or with a restriction on the source text (requiring `"use module"` or `export {}` or...). It's not the committee's job to endorse a solution for each host environment. And it's certainly not the committee's job to add artificial restrictions to the language so that the restrictions in place in one host environment are also enforced by other host environments. (Otherwise, Node would never be allowed to use FunctionBody in the first place as its goal symbol!)
> 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.

I think you'll find that reasonable people, including many committee members, will disagree with your assessment of what is better and cleaner. Furthermore, since agreement on this subject is not really germane to the committee's focus (since it is a question for host environments, not the base language) there's no a lot of urgency for the committee members to force each other into agreement. Instead, the various people in charge of the host environments are best off making their own decisions. If they find the committee's input valuable, they're welcome to consult committee members, but given that reasonable people can disagree, you'll likely get different suggestions based on which committee members you talk to.

More information about the es-discuss mailing list