I don't see a need for it. Module loaders these days can easily distinguish CommonJS modules from ES6 modules (f.e. JSPM.io does that automatically, and so does Webpack and Browserify with plugins). I understand that right now we can't `require` es6 modules using Node's `require` function, but that might be a short-term thing. Once ES6 modules are natively implemented somewhere Node will have to follow suit (if it isn't the first to implement it). In the meantime, just use a transpiler (Webpack+Babel, Browserify+Babel, JSPM, etc). I myself use https://github.com/trusktr/npm-package-skeleton to write NPM modules using the latest language features (ES6 modules, ES7 async functions, etc) and then the `prepublish` script transpiles it all to CommonJS ES5 so that it will work in any end-user's Node.js environment. That's probably easier and faster than going through that whole process with IANA for possibly no gain.
On Mon, Jan 25, 2016 at 11:28 PM, Domenic Denicola <[email protected]> wrote: > Further underscoring how irrelevant IANA registrations appear to be, it > seems IANA currently associates .js with the following “specification”: > http://web.archive.org/*/http://devedge.netscape.com/library/manuals/2000/javascript/1.5/reference/ > > > > > > From: es-discuss [mailto:[email protected]] On Behalf Of > Domenic Denicola > Sent: Monday, January 25, 2016 23:22 > To: Bradley Meck <[email protected]>; es-discuss > <[email protected]> > Subject: RE: File Type for Module Goal > > > > If you would like to register a MIME type with somebody, anybody at all, > then https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority is > probably the right place to do so. They don’t really deal with file > extensions, besides saying that registrations should include a few commonly > used example extensions from one or more platforms, alongside “Macintosh > File Type Code(s)”. The “commonly used” implies to me that you had better > start using the proposed file extension, commonly, before proposing it for > standardization. But who knows. > > > > In practice though, registration with IANA accomplishes nothing, besides > making people feel better about having gone through the proper channels. > What matters is how software uses those registrations. For example, > text/jscript and text/livescript are both accepted by web browsers as > denoting JavaScript, but are not registered with IANA. If making people feel > better is the goal here though, to alleviate “expressed concern,” by all > means go through the IANA registration process. > > > > From: es-discuss [mailto:[email protected]] On Behalf Of > Bradley Meck > Sent: Monday, January 25, 2016 23:08 > To: es-discuss <[email protected]> > Subject: File Type for Module Goal > > > > Unclear on the right place to ask for this, and I am now ending up on > es-discuss. > > > > Node's support for ES modules would ideally be non-ambiguous and not require > parsing to determine the goal of a file ( > https://github.com/bmeck/node-eps/blob/es6-module/002-es6-modules.md#determining-if-source-is-an-es6-module > ). So far we have been met with RTFM it feels like. We were looking at > getting a file extension added to Node for such things, some of the > contributors have expressed concern about using an unregistered file type. > > > > I am wondering if this is the right place to find the person to get a > `+module` suffix added to `application/javascript` so we can officially > register a `.jsm` or `.es` file type. > > > > Places we have been to so far (with confusing directions on where to go from > there): > > > > * TC39 > > * WHATWG > > > > Bradley > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
