Discuss
  • File Type for Module Goal

File Type for Module Goal

# Bradley Meck (9 years ago)

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 ( 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

# Domenic Denicola (9 years ago)

If you would like to register a MIME type with somebody, anybody at all, then 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:es-discuss-bounces at mozilla.org] On Behalf Of Bradley Meck Sent: Monday, January 25, 2016 23:08 To: es-discuss <es-discuss at mozilla.org>

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 ( 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

# Domenic Denicola (9 years ago)

Further underscoring how irrelevant IANA registrations appear to be, it seems IANA currently associates .js with the following “specification”: web.archive.org/*/http://devedge.netscape.com/library/manuals/2000/javascript/1.5/referenceweb.archive.org/*/http:/devedge.netscape.com/library/manuals/2000/javascript/1.5/reference

From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Domenic Denicola Sent: Monday, January 25, 2016 23:22 To: Bradley Meck <bradley.meck at gmail.com>; es-discuss <es-discuss at mozilla.org>

Subject: RE: File Type for Module Goal

If you would like to register a MIME type with somebody, anybody at all, then 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:es-discuss-bounces at mozilla.org] On Behalf Of Bradley Meck Sent: Monday, January 25, 2016 23:08 To: es-discuss <es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>>

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 ( 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

# /#!/JoePea (9 years ago)

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