detecting JS language mode for tools

John Lenz concavelenz at
Fri Jan 24 13:20:55 PST 2014

I'm perfectly happy with convention of some kind:
a) a file extension
b) a comment on the first line of the file:
  // module mymodule
c) a "use strict" style annotation that is just documentation:
  "module mymodule";

The key thing in my mind is that TC39 pick something and encourage it.

On Fri, Jan 24, 2014 at 11:38 AM, Allen Wirfs-Brock
<allen at>wrote:

> On Jan 24, 2014, at 9:32 AM, David Bruant wrote:
>  Le 24/01/2014 18:26, John Lenz a écrit :
>>  REPL is a dilemma: if you parse as module, then obtaining the last
>> expression value is not simple. if you parse as a script, then common
>> cut/paste fails on export/import statements.
>  My basic question remains.  As a tool owner how do I know if what I'm
> looking at is intended to be a Module or a Script?
> How do you know if some code is intended for the browser or Node?
> How do you know some code is intended to be used in a WebWorker and not in
> the main thread?
> How do you know the code won't be concatenated a "use strict" when someone
> else uses it?
> The code itself lacks the context in which it's being loaded (hence very
> defensive patterns like UMD (Universal Module Definition)).
> If you want to be exhaustive, you'll have to make an assumption or make
> your tool smarter about the context.
> I've had some discussion with Dave Herman about this and I think there is
> a plausible way to handle it.  I'm not sure if Dave would totally agree
> with 100% of the following but I think it is close to  what seemed to make
> sense in our discussions.
> 1) there are some very good technical reasons for having two syntactic
> goals (script and module) corresponding to the two semantics.
> 2) A module with no imports and no exports is essentially a new form of
> top level code that is always strict mode and but has its own "file level"
> scope.
> 3) In browsers, html syntax (new attribute on script tag, etc.) can be
> used to distinguish the two. Dave is working on this.
> 4) but there are other situations where the intended syntactic goal of a
> source file need to be identifiable.  For example, when listing source
> files on a command-line invocations of a JavaScript engine or tool
> 5) Humans when reading or managing code files also need to know which kind
> of JS source file they are dealing with.
> 6) typically we use file extensions to make distinctions of this sort.
> 7) Hence, it probably makes sense to promote a convention of using a new
> file extension for ES6 source files that are intended to be parsed with the
> modules goal.  .jsm, or mjs, or something similar that is appropriately
> suggestive and isn't already widely used as an extension.
> Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list