detecting JS language mode for tools
concavelenz at gmail.com
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:
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 wirfs-brock.com>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"
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss