Vote on ES module detection

[bmeck]

In order for the EPS for ES modules to progress we need a definitive vote to choose between:

• Using a new file extension for ES modules such as .jsm
• Using a few new package.json fields
  • main -> module for ES module entry point
  • modules to list all the .js files in the package that should be treated as ES and not CJS.

The full discussion is in nodejs/node-eps#3

A sidecar discussion specific to module detection is in nodejs/node-eps#13 (comment)

[jasnell]

/cc @trevnorris @nodejs/ctc

[mikeal]

I'm a little concerned about this.

There are a few too many externalities for this to be voted on strictly by Node.js contributors.

[bmeck]

@mikeal the determination is not solely based upon this, but I am having trouble since people continue to ask for a head count of votes. There also needs to be a clearer way to make decisions on highly debated topics.

[mikeal]

There also needs to be a clearer way to make decisions on highly debated topics.

This is definitely true. But this is specifically within the Node.js project, we can't be expected to get an accurate vote or representation from outside of self-identified Node.js developers.

This has a much broader effect than what I feel we have the capacity to represent. I understand the concern, and the complaints, and I also know that there is a lot of tension because of the feeling that TC39 is not representative of our interests, but I don't necessarily think that the solution is push forward with our own unrepresentative decisions.

[bmeck]

@mikeal the proposal has input from TC39 both ways, as well as input from those who are front end. What are you looking for in order to make this decision? If there is not a definitive requirement my request for a vote will still stand. Do we need to form a separate standards body prior to this decision?

[bmeck]

To note:

• TC39 as a body is not concerned with how mode is detected ( Add application/javascript+module mime to remove ambiguity tc39/ecma262#322 )
• Browsers solely use content-type and type=module which is independent of this decision ( add +module to mime type for script type=module whatwg/html#558 ).

[mikeal]

@bmeck yes, it has input from a broad base, but I would assume those voting here would have voting rights associating with their committer or TC membership status in Node.js Core, which is not as representative.

[trevnorris]

@mikeal There's a misunderstanding of what a vote from the CTC represents in this case. We are voting on whether or not the implementation presented in the EP is an implementation node core is willing to adopt. Our vote does not directly reflect the ultimate decision of the TC39 spec, and if ultimately the spec were to deviate from the EP then we would work with it.

We have received external requests on how node would like this implemented, and it is our responsibility to make sure our voice is heard. Especially in a change so substantial it will alter a basic component of the node ecosystem.

These external requests have asked "what is an acceptable implementation for node?" This EP is the result of substantial discussion and debate. As such, we will not please everyone, but irregardless the external requests have a deadline and that is now.

Again this is not authoritative or even irreversible but it is necessary.

[ChALkeR]

@bmeck (also /cc @ljharb), I remember that we tried to sum the proposals up at https://docs.google.com/spreadsheets/d/1aC2kPwpahPnTjFmfb9EL2hFoNl7NhRGbdh6UG3VG3XU. I hadn't been keeping an eye on this for some time, are there any new proposals that are not listed there, or is anything there out of date?

[ljharb]

An ideal outcome, in my opinion, is one where someone could write up a few straightforward instructions to follow that would encompass the "best practice" for using CJS and ES6 seamlessly, across browsers, node, build tools, and editors.

In other words, I don't think it's important to please everyone - I just think it's important to the entire ecosystem that every corner of it shares a cohesive story, even if it's a bit less convenient for some.

@ChALkeR I don't agree with some of the degree of the colors on there, but i think the list is complete and accurate otherwise.

[trevnorris]

@ljharb Many of those have already been discussed (i.e. pragma or content-sniffing) in the linked EP or associated issues. The presented solution in the EP was reached after much debate.

@bmeck Mind chiming in on these?

[ljharb]

@trevnorris Definitely! i currently believe that a .jsm approach in node is the best one to achieve the ideal outcome I described.

[JacksonTian]

I prefer .es.