treated as a module if ...
d. If a source file is imported it is parsed using the Module production.
Thanks for the quick reply! Does this mean that a file that contains imports, but no exports, is not by default evaluated in strict mode?
No. This all comes down how the file is evaluated and that is determined whether the file is treated as Script [1] or Module [2]. Modules are always strict and Script is sloppy unless it starts with a use strict directive. Traditionally all source files have been treated as Script but in ES'15 we provide another hook for the embedder to invoke which allows the source file to be treated as a Module [3]. The idea is that the module loader spec [4] will use this hook.
[1] ecma-international.org/ecma-262/6.0/#sec-scripts [2] ecma-international.org/ecma-262/6.0/#sec-modules [3] ecma-international.org/ecma-262/6.0/#sec-toplevelmoduleevaluationjob [4] whatwg.github.io/loader
HTH,
Erik
To be explicit: there is no way to look at a string of JavaScript text and tell whether it should be treated as a module or a script. In many instances the same string can be treated as both. The decision is made by the execution environment.
On Sun, Jul 5, 2015 at 8:46 AM, Domenic Denicola <d at domenic.me> wrote:
To be explicit: there is no way to look at a string of JavaScript text and tell whether it should be treated as a module or a script. In many instances the same string can be treated as both.
The decision is made by the execution environment.
I don't think Domenic meant that the standard explicitly states that the execution environment may choose the parse method. Rather that the context of loading the code determines the parsing method.
I believe that the current status is that the standard describes the two parsing methods but says nothing about when they will be applied. We do know that <script> tags always parse as Script. Of course, modules
imported by import statements are parsed as Module. Sadly, as far as I know, there is no standard way to import a ES2015 root module. The discussions on modules imply that there will be an explicit "loader" import function that will parse as Module and there has been discussion of <script type="module"> and <module> but these proposals are moving slowly if at all.
On Jul 6, 2015, at 7:32 AM, John Barton wrote:
On Sun, Jul 5, 2015 at 8:46 AM, Domenic Denicola <d at domenic.me> wrote: To be explicit: there is no way to look at a string of JavaScript text and tell whether it should be treated as a module or a script. In many instances the same string can be treated as both.
The decision is made by the execution environment.
I don't think Domenic meant that the standard explicitly states that the execution environment may choose the parse method. Rather that the context of loading the code determines the parsing method.
I believe that the current status is that the standard describes the two parsing methods but says nothing about when they will be applied. We do know that <script> tags always parse as Script. Of course, modules imported by import statements are parsed as Module. Sadly, as far as I know, there is no standard way to import a ES2015 root module. The discussions on modules imply that there will be an explicit "loader" import function that will parse as Module and there has been discussion of <script type="module"> and <module> but these proposals are moving slowly if at all.
In other words, every tools (including command line based execution engines) that parse ES2015 source code really needs to make provisions for the user to identify how each source file will be parsed. It might be with a command line flag or by interpreting extensions, or some other way.
For example, traceur ( google/traceur-compiler/wiki/Options-for-Compiling ) defaults to parsing source files as modules but provides a command line switch for identify file that need to be parsed as scripts:
traceur --script main.js mod1.js mod2.js
apparently will parse main.js as a script and mod1.js and mod2.js as modules.
It would be nice for a common command line convention to emerge that all js source level tools followed. How about tool developer put your head together and decide on something.
I thought at one time a naming convention was proposed: x.m.js for es6 modules. But I haven't seen any traction for it.
On Jul 12, 2015, at 2:05 PM, John Lenz wrote:
I thought at one time a naming convention was proposed: x.m.js for es6 modules. But I haven't seen any traction for it.
various file extension conventions have been floated, but nothing seems to have caught on.
Fill in the blank. In ES 2015, a JS source file is treated as a module if _____. a. it exports anything b. it imports anything c. both a and b d. something else
R. Mark Volkmann Object Computing, Inc.