detecting JS language mode for tools

John Lenz concavelenz at
Fri Jan 24 10:26:38 PST 2014

As long as you can import from a script in some fashion: Loader.import
works for me.

I'm a little concerned that "import/export" will need to work as a "use

On Fri, Jan 24, 2014 at 9:55 AM, John Barton <johnjbarton at> wrote:

> If we are asking questions: why two parse goals? Why not allow import in
> Script and let it act like the code was wrapped in Loader.import() and
> allow export then just ignore it?  The semantics of 'var' would be changed
> by appearance of 'import' just like the semantics of code changes with the
> appearance of 'use strict'.
> On Fri, Jan 24, 2014 at 9:32 AM, David Bruant <bruant.d at> 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.
>> David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list