WRT PR #3 - ES module detection

[bmeck]

This is the place to discuss specifics of how node will determine the mode a given a source (file / source string). Source string examples include stdin or -e, they do not include JS Function or eval calls. The proposal itself can be seen in PR #3.

Discussions here should regard:

• Ways to detect the module target for a specific source
• Impact of detecting the module on other environments
  • How other environments will provide the detection in the case of interoperability
• Potential incompatibilities introduces for existing workflows with module detection possibilities.
• Transition goals for a time when ES modules are the normal target.

Note: CJS will be the default target of node for the foreseeable future, "normal" here means what developers write daily. This is a constraint that can be easily worked around for a single source via a cli flag to note that the source is an ES module. This flag should not be seen as relevant to the discussion in this thread.

Note: We are only discussing choices that do not require parsing of the source file.

It should not discuss import/export conversion, evaluation ordering, or module path resolution.

[jokeyrhyme]

Is it appropriate to discuss the ".jsm" extension proposal here? Or does it belong elsewhere? Or has that proposal been definitively rejected?

[bmeck]

@jokeyrhyme yes, you can discuss various approaches such as .jsm, package.json, etc. here. .jsm is not rejected, and many still favor it.

[balupton]

I've tried to do a recap of the options for this at https://github.com/nodejs/node/wiki/ES6-Module-Detection-in-Node

Personally, I'm proceeding with the userland solution of editions - with the current implementation of editions, there is import and require syntaxes - https://github.com/bevry/editions/wiki/Syntaxes - that could be used for such detection, a directory property could also be added to each edition, if we go that route.

---

@bmeck thanks for splitting this up

[bmeck]

@balupton lots of those are in the proposal / please avoid putting things that have not been agreed upon in the node wiki as it may confuse people. Feel free to paste all that in here and we will discuss it. I disagree with a lot of pro/con points and discussion should be had on them.

[balupton]

@bmeck point of the wiki page was to summarise all points, not just those agreed upon, so as to avoid having to read the entire previous thread for such depth, it should be expanded rather than truncated - discussion should happen here yes, however I see no wrongdoing with maintaining a comprehensive up to date concise summary of all points

[jmm]

I understand that there are a lot of objections to the idea of trying to inspect the source to detect the format, to the point that in the original thread people keep saying it's a dead issue, off the table. But yet it's still mentioned here, so as long as it's still in the mix I think the export {} idea I mentioned should be in the picture.

Something like a "use module" pragma would impose an authoring tax on every file, even though most ES6 modules will already organically include at least one import|export that unambiguously establishes its type. That'd leave probably just a tiny fraction of modules, like those that are only for side-effects, that require authors to opt-in with some explicit indicator of type. Instead of something invented like "use module" that could just be module syntax: export {}. @balupton Per your wiki, with this suggestion in mind I think the implementation side is the huge obstacle, not the authoring side.

[bmeck]

@jmm @balupton updated the wiki, it was missing a fair amount of information. Noted things that caused rejections like the pragma "use module". Also linked to proposal to answer "still unclear" points. Please read the file in the proposal before making new statements.

[bmeck]

warning, in 2 weeks module proposal for node will be taking file extension unless package.json complexity and workflow concerns are addressed. If those concerns are addressed we will happily delay the decision. I will be confirming against the @nodejs/ctc that this is not a problem in this time as well.

[dead-claudia]

Which one? Or is that still to be determined?

On Thu, Mar 10, 2016, 14:14 Bradley Meck [email protected] wrote:

warning, in 2 weeks module proposal for node will be taking file extension
unless package.json complexity and workflow concerns are addressed. If
those concerns are addressed we will happily delay the decision. I will be
confirming against the @nodejs/ctc
https://github.com/orgs/nodejs/teams/ctc that this is not a problem in
this time as well.

—
Reply to this email directly or view it on GitHub
#13 (comment).

[bmeck]

@isiahmeadows https://github.com/nodejs/node/wiki/ES6-Module-Detection-in-Node#option-4-meta-in-packagejson

Notably:

• Node allows requiring files that are not part of packages
• Will persist in perpetuity and have hints of previous Script goal
  • mitigated but present
• Causes tooling to need to perform JSON parsing per module resolution
  • speed mitigated by cache, parser requirement not
• File semantics are no longer self contained to the file

As per the options, they differ for various ways to put things in package.json

[bmeck]

It should be noted that the file extension has a sizable impact as well. It is not with a happy heart I choose between either.

Also, the package.json thing would be confined to node, and we have several people wanting a simple way to determine goal for non-node projects (many of which do not have package.json).

[balupton]

@bmeck "Is there any plans to support files that use both module systems (aka CJS+ES Modules)?" is specifically about a file that supports both, rather than a package that supports both, here is a contrived example:

import a from 'a'
const b = require('b')

export b
module.exports = a

Another phrasing would be, does each file have to be exclusive es modules, or exclusively node modules, and never mix and match in a single file.

This arose once or twice in the other thread, but I couldn't find anything clear about it, hence why it is there, doesn't seem raised in the proposal explicitly - perhaps is implied somewhere and I didn't notice.

Currently with the babel compiling, mixing and matching module systems in individual files is already being done.

---

great work with the wiki updates! 💃

[bmeck]

@balupton that is not supported, @kittens tried that rabbit hole in babel, it is pure zalgo. If you are in the Module goal there is an exports object as specified in the proposal, but it is a ModuleNamespace. require continues to exist in the Module goal as well. Is there a reason you want a mixed goal in particular?

[balupton]

@bmeck

Is there a reason you want a mixed goal in particular?

Just raised myself because I know of babel compiled projects that do such mix and matching.

I've found myself having such quarrels too, specially with optionally required dependencies (a dep may only need to be required under special circumstances, e.g. for a specific function call which in the majority of runs will never be called), or with dynamic dependencies (e.g. require(somevar)) - both currently work beautifully with require.

[calebmer]

I subjectively fear losing the js extension forever. It's iconic. There’s a joke that if you pick a noun there’s going to be a library with a JS appended. If we adopt the extension proposal do we also have to extend the joke to JSM? Some of the technical implications of the extension proposal really scare me, but what about the cultural implications? What about the new developer implications? File extensions are an aesthetic and losing the js aesthetic worries me.

I think @jmm’s suggestion of export {} is a really good idea and I agree with him in that parsing should be discussed more. Given their are negative impacts, but the negative impacts of an extension and package.json approaches are much worse.

A parsing solution does not impact in place systems. In place systems can happily assume CommonJS. An extension approach, however, widely impacts multiple software ecosystems. Whereas a parsing solution only effects new code.

[balupton]

How about file.jsm.js or file.esmodule.js - would offer same benefits of extension option without impacting ecosystems as abruptly

[bmeck]

@balupton as discussed in the original PR thread, that is not how many toolchains work, they only read the final extension (this includes node itself).

@calebmer can you discuss the technical implications. There are many problems with parsing, and polyfills are a very common instance of side-effect only modules.

[ljharb]

@calebmer in-place systems being unable to use ES6 modules is a massive impact.

[calebmer]

@bmeck ok, and I'll address the side-effect only concern and the other CONs listed in the wiki. But first I'd like to offer three observations:

First, we have to remember that no solution can be ideal. The ideal scenario would be that the ES module specification was around at node's conception so that modules could be supported from the start. That didn't happen, so we now have the tricky task of picking a way to add module support to node whilst not breaking the ecosystem. The parsing solution mirrors most closely what node would look like if there was module support from the start.

Second, theoretically the parsing could be as simple as a regular expression matching export statements. Yes it loses the nuance of a full parser, but a regular expression would be an optimization which could solve for costs on large files and costs for performance critical requires. This also solves for a few other CONs listed on the wiki such as implementation complexity and toolchain detection.

Third, the extension, package.json, or any other approach may be implemented in parallel as an optimization to alleviate some of the costs. If the extension approach were also implemented I'd recommend, .jsmodule and .jsscript to toggle the parsing mode.

Now to counter arguments.

Side-effect only modules.

Most of the time a side-effect only module could easily be a script (optionally with a use strict pragma). If for some reason it has to be a module then, as @jmm suggests, the module could add an export {} to the file. Then node could identify the file as a module and treat it accordingly.

The intersection of side-effect only files and files which must be a module is very tiny, and the tax of a single line is insignificant and comparable to use strict pragmas of the past.

Toolchains require a parser.

Many tools which need to know the difference between a script and a module already have a parser, furthermore many more tools don't even need to tell the difference. For the select few tools which need to know the difference and can't use a small parsing solution from NPM, these tools can use out of band configuration. Take for instance the package.json proposals, these proposals fit well when it comes to specialized tooling.

Furthermore, tools that can't have a simple parser for NPM often aren't in the node ecosystem (I'm thinking of Ruby, Python, or other ecosystem tools). These tools are dealing with client code, not node code.

Large files.

Considering Babel and other parsers currently can work with large files I'm not entirely sure why this is a large concern. If we use a regular expression parser and a parallel file extension like I recommend these pains can also be alleviated.

Solutions may also include:

• Limiting file size to an outrageous number.
• Defaulting to CJS if no export statement was found in X characters (this allows the placing of an export {} at the top of a file to coerce the parser).

Performance.

In a normal project, all dependencies will be imported/required at startup time which is less critical for performance. However, in some scenarios this is not the case. In areas where dynamic requiring must be performant we can look into various algorithm coercing approaches. For current packages we can also look at the package.json, if it specifies a node version before ES modules we can default to the script goal.

[calebmer]

@ljharb sorry for any miscommunication. I meant in-place systems won't be negatively impacted by a parsing solution, a parsing solution would be neutral. I was referring to the .htaccess and similar configurations argument against the extension approach.

[ljharb]

@calebmer one common use case where a parser won't work is Airbnb's rails app - which uses Sprockets, which sends JS files to an entirely different box for compilation. It will have to know what is an ES6 module or not so it can send the right metadata to the compilation service - but it has no JS engine to do so. Also, perhaps you haven't tried reading JSON in POSIX, but "not needing a parser" is pretty critical in some places :-)

[calebmer]

@ljharb A couple questions as I don't entirely understand the Airbnb-rails-sprockets-node relationship. Why can't Sprockets choose to implement its own format (maybe extension)? Why can't the compilation service make the detection? If the detection of modules were as simple as a regular expression would this alleviate concerns?

It seems to me that services, like Sprockets, have a little more freedom then node to make large breaking changes. If Sprockets wanted to assume everything was a module or everything was a script it could.

[ljharb]

@calebmer the problem is that it doesn't want to assume that - we need to be able to gradually migrate our codebase from script to module. We also don't want Sprockets to implement something that wouldn't work with npm test, or all our node-based tools, for example.

[jokeyrhyme]

Do we need to know which mode we are in prior to parsing?
Which mode-sensitive use cases do not ultimately involve parsing?
Couldn't the airbnb-rails-sprockets-node use case be solved by simply not updating the version of Node.js used until the rest of the required changes (if any) have been made?

[jmm]

I don't have time to respond to everything here right now, but regular expressions are not adequate for detecting this, though like you said a regex or substring search could be useful as a quicker preliminary check to see if import|export is in the source at all before doing an expensive parse, like detective does.

Defaulting to CJS if no export statement was found in X characters (this allows the placing of an export {} at the top of a file to coerce the parser).

I think it's possible that placement in the source could be used to optimize this detection, as I mentioned in my original post:

especially if people are encouraged to place the code early in the source

But making it dependent on that would probably be too fragile, though I did try something like that with browserify for recognizing its own bundles. (That's a much more limited scenario though since it's designed to check its own output.)

[jmm]

@ljharb

We also don't want Sprockets to implement something that wouldn't work with npm test

What would be an example of that? (Probably makes no difference to the issue at hand, I'm just curious what you mean.)

@jokeyrhyme Yes, because they're different goal symbols and modules are implicitly strict. People might have expanded more in the original thread.

[ljharb]

@jmm just responding to the question "Why can't Sprockets choose to implement its own format" - the answer being, because one-off snowflakes are not ideal for being cohesive with the rest of the ecosystem/toolchain.

[mgol]

@cref You misunderstood. If Node ever dropped support for the whole current npm package ecosystem, someone would fork it to a version that kept CommonJS support. People would never upgrade to a Node version that dropped CommonJS, they'd migrate to the fork that keeps the support. The newest Node version would get abandoned and - maybe - in the future the fork would be renamed back to Node.js.

So we'd end up exactly where we are now, the only difference would be a lot of problems with yet another fork in the meantime. What's the point?

[mpcref]

exactly, the name is not relevant, thanks for the confirmation. now where did I suggest stopping support? starting a new version !== ending support. ask microsoft. and why would you fork node for something you could just as easily solve with a library? is it because... you can't, because actually, require isn't conceptually the same as import and therefore might lead to a suboptimal compatibility layer when done as a library as opposed to a fork? better make the fork an official one then. hence, new version.

anyway, I'm done, got some forking to do! :-P

[dead-claudia]

Public Service Announcement

TL;DR: Please remain respectful, and don't blindly reject others' viewpoints without taking the time to explain why they're wrong, not why you're right.

---

I feel this discussion has somehow degenerated to the point it's borderline off-topic and not exactly productive, to put it lightly. Not pointing fingers, but could we at least listen to those collaborators here, most of whom having been involved with Node.js for most of its history?

Oh, and if you feel someone's logic is off, please actually try to debunk it rather than just restating your point. Doing the former is proving them wrong, and it's usually something that you can do without even stating your side at all. Doing the latter will convince no one who doesn't already agree with you, and it'll make you look much less nice or respectful.

To summarize, please remain respectful, don't be dismissive, and do consider the other side. You might be surprised what you would learn with an open mind! 😉

[chrisveness]

@isiahmeadows I agree entirely; but I would like to point out (hopefully respectfully) that I think there is a sense that when it comes to .mjs, the CTC is rejecting others’ viewpoints without explaining why e.g. In Defense... or TC39 spec changes wouldn’t work; this sense is only reinforced by an attitude of “what node does, everyone else will follow”.

[mpcref]

Good point @isiahmeadows . All I'm doing here is offer some outside-of-the-box alternatives. IMHO, what's the most important aspect about es6 modules is the fact that it's a format optimized for both filesystem-based and web-based usage. Adding support to Node.js by introducing yet another file extension that's implicitly being searched for when fetching a module undermines the modular aspect for web-based platforms and would force web developers to still use additional build tools.

Let's just wait until the Loader spec is finalized and then see how best to support loading Node.js-flavoured CommonJS through import.

[ljharb]

Web developers already have to use additional build tools to get anything useful done - that's the new reality.

[chyzwar]

Web developers already have to use additional build tools to get anything useful done - that's the new reality.

Please do not conflate back-end and front-end development. There is number of language that do not require any additional tooling: go, Java, PHP, Python etc.

Currently in node.js we barely have any editor support: auto completion, debugging, profiling. Node is now planing to introduce forced marriage between ES6 Modules and CLJ and make whole thing even worse.

Can someone designing interop can confirm following:

import {join} from 'path'

This will load only join or whole path module?

import {sharedApi} from 'https://cdn.syndication.twimg.com/api.js'

1. Can I load a module from web in node.js ?

const sharedApi = require('https://cdn.syndication.twimg.com/api.js');

1. If full interop is provided then this should work as well?

const {something} = require('esModule')
const something =  require('esModule').something

1. Named exports will be treated as object properties?

import myModule from './myModule.js'

1. If I providing relative path do I still need to use .mjs extension?
2. If whole module only use ES Module can I only use .js?

export default const something = {}
exports.default =  {}

1. What if module provide both types of exports ?
2. With module export would take priority?

[bmeck]

@chyzwar please read #39 for answers regarding most of these.

import {join} from 'path'

1. No, it parsing the full source of "path" according to the specification. Tree shaking / Dead code elimination is done by tooling outside of ECMA262 (the JS spec). JS spec does not include such a feature, it is purely tooling.
2. Named imports from CJS are not possible for a variety of reasons.

import {sharedApi} from 'https://cdn.syndication.twimg.com/api.js'

Won't work. Only file:// is supported until security is fully worked out for networking. Other protocols that work in the browser like data:// are not supported either for initial implementation.

const sharedApi = require('https://cdn.syndication.twimg.com/api.js');
const {something} = require('esModule')
const something =  require('esModule').something

1. Can't load off network still.
2. require is tentatively unable to load ESM since you can use import() everywhere.
3. Yes, the spec has a mandated type for what ESM look like when turned into objects. This exposes getters for each variable.

If I providing relative path do I still need to use .mjs extension?

Open issue : #51 , current judgement is that you do not, but some people on browser side are concerned about that. Note, web browser support .mjs so it is not a problem if it is included optionally.

Searching so called "bare" URLs (things in node_modules/) are expected to always have search behavior.

If whole module only use ES Module can I only use .js?

Not planned. Added complexity and does not focus on a future where there is a uniform way to produce code for ESM. This affects both browser vendors and node; both are well aware of the situation.

What if module provide both types of exports ?

This is not possible according to the JS specification due to:

1. immutability constraints
2. removal of magic CJS variables

With module export would take priority?

Modules only have 1 type either CJS or ESM. Therefore there is no priority since there is no competition.

I would note that interoperability does not mean 100% compatible in both directions for our goals. Node is not going to limit its features to web browser APIs, and web browsers will not allow the same features as Node. import falls on the line of this as it determines how features get loaded, I doubt there will ever be a case where import "fs" works in browsers truly, and I doubt that node would load untrusted scripts from 3rd parties as easily as browsers since it needs more direct access to the system.

[bmeck]

The implementation of ESM has started, I am going to close this. If you have specific concerns about pathing or a problem with the file extension, please open a new issue. General concerns have been covered here in depth.

[dead-claudia]

@chrisveness

the CTC is rejecting others’ viewpoints without explaining why e.g. In Defense... or TC39 spec changes wouldn’t work

I am also aware of that, but they have already previously addressed nearly every viewpoint presented here in the last week viewpoints earlier in this issue, #3, #39, and other related issues. It would've been definitely more helpful and productive if more of them had linked to previous discussion to justify their dismissal, but I do agree with their unwillingness to accept these arguments which have been covered multiple times already. (I've been passively involved and watching this closely since about a month after #3 was filed early last year, and I haven't seen much actually new come up in the last few months.)

But on that note, this issue is closed, so I'm going to drop the issue now.

[gabrieledarrigo]

Hi! Where can fe follow the development of ESM?

[shelby3]

Lol, Node.js forking itself away from the ECMAScript ecosystem with a proprietary file extension total order on the universe and conflated interroropt of module specifications. Purrrfect.

[ljharb]

@shelby3 that comment isn't productive or accurate. Browsers ignore file extensions entirely; ECMAScript is a spec, not an ecosystem; people use .jsx all over the place just fine.

Again, the reality is this: a file extension is supposed to mean only one thing: "here's how to parse this file". The creation of a second parsing goal in the language - Module - inevitably ensured the creation of a new file extension to indicate "parse this file as a Module". .js is already irrevocably used as "parse this file as a Script" everywhere but in browsers _{(which use <script type="module"> to determine that it's a Module)} and browsers are informed by the webserver who chose that tag, which is in turn typically informed by the file extension.

Feel free to suggest a better alternative, but the only possibility for avoiding a second file extension vanished when the language spec shipped a second parsing goal. That may be unpleasant for people - but that doesn't change the reality.

[SEAPUNK]

Just curious: Does the browser require the returned MIME type (via Content-Type header) to be something specific for it to execute the file as Javascript? I'd imagine that CDNs and other web servers, until they add a mapping for the .jsm (or .mjs, or whatever it'll be) extension, would return the .jsm JS module files as application/octet-stream.

[chrisveness]

I like that Node.js has become "everywhere but in browsers".

[ljharb]

@chrisveness do you know of non-node non-browser tools that take no out-of-band instructions (including "the only paths it accepts are JS files") and know something is a JS file by something besides the .js extension?

[shelby3]

@ljharb wrote:

The wider JS community uses node-driven build tools, as does the entire npm ecosystem. What node does, everyone else will follow.

Pride cometh before thy falleth.

Other things (e.g. TypeScript) are gaining momentum and eventually they might decide it is a lower priority to keep pace with more Node.js aberrations, especially after this epic fiasco causes more people fork away from Node.js.

but the only possibility for avoiding a second file extension vanished when the language spec shipped a second parsing goal

TypeScript determines what is a module by whether it contains any top-level export annotations.

that comment isn't productive or accurate.

As @chyzwar, @cref (and to some extent @chrisveness) have explained (which I consider carrying forward the original points I made in this thread last year), trying to backport require to support both ESM and CJS is a “can of worms”. A clean separation (eventually deprecating require if ever CJS use diminishes sufficiently) provides more degrees-of-freedom and does not muck with the wider ecosystem of tools by introducing a proprietary file extension that further fractures the JavaScript ecosystem (see the point about complexity budget near end of this post). I had even proposed as a compromise a hokey heuristic use module as way to embed the ESM attribute (as opposed to a file extension) but afair, before that I was preferring instead to not overload require for the different module formats (which was thus congruent with and prior art for what these 2 or 3 guys seem to be proposing). Periodically we have to reset away from maintaining legacy complexity, else the rigor mortis morass devolves.

Also unnecessarily providing two ways to do the same thing (i.e. import or require ESM modules) which have to be maintained into the indefinite future, violates a fundamental principle of good design, as well is incongruent with maximizing readability of source code— which is a very high priority in the open source era.

You all the gatekeepers who are in control of the intended echo chamber, groupthink here, want to make it very easy for old code to be switched over to ESM by changing the module file names instead of changing all the require keywords to import in the source code. Yet @chyzwar has explained that this presumed convenience is not even that clearly to work out, and the potential complexity for clusterfucking into the future is unpredictable. Even though he was talking about type inference, I think the general gist of a wiser elder from the C++ design process (in his 60s and I am in my early 50s) @skaller’s thesis is applicable to trying to make many small special case implicit conveniences as Node is doing in this case and ending up with a jumbled, rigor mortis mess of complexity eventually:

@skaller commented on Oct 10, 2016:

_{Implicit quantifiers do NOT make code easier to read. Its like most “simplifications”,
they seem like a good idea at the time, they work well for simple cases,
but its a disaster precisely in the cases where you think it would serve best,
the complex cases.}

_{Its a known fact that human information transmission requires redundancy.
Perhaps less for smarter people, or people familiar with the domain,
more for others. But for language, psychologists have actually MEASURED
the amount of redundancy that gives the best comprehension, its somewhere
between 15 and 30% I believe (in linear text).}

_{Computer programming languages may require different redundancy.
but infering types everywhere clearly defeats the whole point of having
type annotations: to provide redundant information for validation and
confirmation.}

Regarding exceeding the complexity budget, please see the comment quoted (not my comment but rather some very smart programmers who visit 160 IQ genius Eric Raymond’s blog) near the end of this post about how horrendous JavaScript’s chaos has become.

Edit: I had mentioned this complexity overload in my first post last year, and even pleaded to be respectful of the users like myself. The complexity is so bad that no one without days to kill can even wrap their mind around all the epic volumes of arcane discussion that a reader is slammed with. K.I.S.S. is important. Transitioning towards one module standard that works every where is the sane direction that reduces complexity over time.

edit:

edited by @MylesBorins. replaced unfortunate choice of words with "echo chamber". I believe that keeps original intent in tact

[ljharb]

@shelby3 please don't use inappropriate terms like "circle-jerk" - https://github.com/nodejs/TSC/blob/master/CODE_OF_CONDUCT.md may be helpful.

(I'll be happy to delete this comment after/if you edit your post)

[shelby3]

@ljharb, the COC says you should not accuse my joke of being not productive (passive aggressive political control methodology) which you (and your cohort gatekeeper) also did to me last year, when it was a concise way of pointing out my technical objections without getting into another fight with you gatekeepers. Since you responded that way, I responded in kind. I tried to keep it light and humorous, but you want to fight because you are sure you are correct and everyone who disagrees with you is wrong.

Edit: last year I even I tried to convince the politik to leave the ad hominem aside, but was unsuccessful.

Sent in a private msg just now:

Reviewed that ES6 Modules and Node.js thread. And found some links to where those two gatekeepers took the purely technical discussion off into ad hominen.

Without the perspective of the history of that thread, one might conclude incorrectly about my latest comments. Rereeading that thread convinced me that I was not acting inappropriately. And I often cringe when I re-read some of the stuff I wrote in the past, so if I did not cringe when re-reading that thread, then I think it is reliable indication that I did not act inappropriately.

[gabrieledarrigo]

Ok but, anyone knows the status of the work on ES modules?

[benjamingr]

@shelby3 it sounds like you have some interesting arguments to make and discussion was conductive until 2-3 messages ago.

I realize that strong opinions sometimes lead to strong language or terminology but Node really cares about being a nice environment and it would be a shame if we missed your insights into the problem (to be clear, completely serious here) because of the way discussion is had.

I realize it's a little unfair to ask you to have discussion in the particular way we're asking and that you're entirely within your right to refuse - but I would much rather prefer you stick around :)

[snuggs]

@benjamingr amazes me how we are fumbling the ball on the .es extension. I mention it to people and they look at me like i'm crazy. .es was registered in 2006 as the .es module file format for application/ecmascript. I use it in all my code these days and i can immediately differentiate if i'm working with modern ECMAScript vs something the browser likes (that I will never look at). Maybe i'm not covering as large a space as you all are but I contribute to many OSS projects and many have said it's actually not a bad idea after showing them the specification for the format.

Only "patching" i've had to do is require.extensions ['.es'] = require.extensions ['.js'] on the node side and off to the races. And i send modules across HTTP/2 as application/ecmascript with .es extension for "modules" and the browser knows no difference. I send application/javascript and .js for bundles. Also in WHATWG spec as parsable javascript mimetypes. May be oversimplifying but seems like a ton of bike shedding going on IMHO. Was mentioned to me on Twitter "TC39 didn't make that extension so can't use it." However I don't think TC39 created the .js extension back in the netscape days either. Seems like we are creating a rounder wheel.

Pardon my ignorance for not knowing what I don't know.

Respectfully.

// Project using all .es extensions
https://github.com/devpunks/snuggsi

// .es file extension -

[dead-claudia]

@snuggs It's been considered from the start, but @domenic isn't the only TC39 member who very strongly dislikes anything resembling "ECMAScript", and other proposed extensions like .mjs/.jsm/.m.js/etc. make a little more sense for drawing the distinction between script and module code.

[webmobiles]

please, make node support ts, typescript 2, we don't need anymore js es5 or es6 lol

[objectkit]

I am adding my voice to reenforce @snuggs comment above. If there are branding issues at play, then at least dual standard support for .es and .mjs

[ljharb]

@objectkit bikeshedding between extensions is one thing, but i don’t think having both would be a good idea.

Specifically, .es implies “ecmascript”, but Script is just as much ecmascript as Module is, so it doesn’t seem appropriate to me to be used for only half of the available parse goals in the language.

[objectkit]

@ljharb I hear you. I understand that having both would not be a good idea, but I do see benefits to it nonetheless.

Yes, es does imply ECMAScript, the name of the language specification, and this is quite different from the languages common implementation name, JavaScript.

I do understand that a file extension standard has to be set as there are no BOM specifiers available to the plain text files used by interpreters, or if so, that most people would not use them. Something has to be done to advance interpreter expectations that contents may reference at least ECMAScript 6+ standards, which of course include modules.

I just feel that mjs is a cumbersome TLA and that es is easier to type and cognise in a large grouping of files. A human bias with interpreter benefits.

• .js <= ECMAScript 5
• .es >= ECMAScript 6

NodeJS is in a very interesting position. It should not be up to Google, Microsoft, or Apple (unsure about Mozilla) make this decision alone, thus the hope that NodeJS will lead the change and support at least both file extension names, even though some or many may see that stance to fly in the face of popular opinion or branding. Lets not forget the implementation name of the language has changed through the years:

• Mocha (Eich)
• LiveScript (Netscape)
• JScript (Microsoft)
• ActionScript 1 (Macromedia)
• JavaScript (Sun/Mozilla/Eich)

I think this one time that we need to prioritise the language standard first and go with, or at least support, es in order to support modules, even if its a completely counter cultural position and presents a bit of a lexical oxymoron.

Soapbox concluded, rationality expected.