what makes a file a module?
A file that is imported is treated as a module. That's it.
It depends on how you access it: if you import the file or load it via <module> then the file is interpreted as a module.
On Sun, Oct 19, 2014 at 1:59 PM, Erik Arvidsson <erik.arvidsson at gmail.com>
wrote:
A file that is imported is treated as a module. That's it.
And you can statically infer that a file is module by reading the source
and scanning for export, which would also mean it's a module. This
wouldn't catch files that don't have an export that are still imported
from some other file.
On Oct 19, 2014, at 1:04 PM, Rick Waldron wrote:
On Sun, Oct 19, 2014 at 1:59 PM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote: A file that is imported is treated as a module. That's it.
And you can statically infer that a file is module by reading the source and scanning for
export, which would also mean it's a module. This wouldn't catch files that don't have anexportthat are still imported from some other file.
As file as simple (or even simpler) as: var x; //---eof------
can be a module. Neither import or export is required in a module. A module is anything that is parsed by the ES implementation using the Module grammar production as its goal symbol.
It is implementation dependent how it is determined whether an individual file will be parsed as a Script or as a Module.
Axel alluded to a possible HTML extension that could be used to distinguish modules from scripts. But, exactly how modules will be integrated into HTML is still under development.
You can imagine various ways that modules might be identified in a command line environment. for example
js script1.js -m mod1.js -m mod2.js script2.js
so of us have argued that a module file extension might be useful in such environments:
js script1.js mod1.js mod2.js script2.js
On Sun, Oct 19, 2014 at 4:23 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
wrote:
It is implementation dependent how it is determined whether an individual file will be parsed as a Script or as a Module.
This seems problematic because it means I can't assume that strict mode will be inferred. That may lead people to always specify it with 'use strict'. I was hoping to not have to do that.
On Oct 19, 2014, at 2:28 PM, Mark Volkmann wrote:
On Sun, Oct 19, 2014 at 4:23 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
It is implementation dependent how it is determined whether an individual file will be parsed as a Script or as a Module.
This seems problematic because it means I can't assume that strict mode will be inferred. That may lead people to always specify it with 'use strict'. I was hoping to not have to do that.
It's not intended to be inferred. In fact, it can't necessarily be inferred from the source code of a module or script. The intent is that the designation of a source file as containing a module or script unambiguously communicated to the ES engine. It is the manner in which that is communicated which is be implementation or host environment determined.
Can we say anything more concrete if we restrict the discussion to modern browsers as opposed to non-browser ES engines? Is it fair to say that in those environments a file will always be treated as a module if it is imported by another file that the browser has loaded?
On Oct 19, 2014, at 5:42 PM, Mark Volkmann wrote:
Can we say anything more concrete if we restrict the discussion to modern browsers as opposed to non-browser ES engines? Is it fair to say that in those environments a file will always be treated as a module if it is imported by another file that the browser has loaded?
Files that are named in the from clause of an import declaration are always parsed as a Module. It is only files that are externally identified (ie, not via an import) that need to be identified as either a Script or a Module.
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Mark Volkmann
Can we say anything more concrete if we restrict the discussion to modern browsers as opposed to non-browser ES engines? Is it fair to say that in those environments a file will always be treated as a module if it is imported by another file that the browser has loaded?
Concretely, the plan of record (which may change as implementation realities descend upon us) is:
- Any code inside
<script type="module">will be parsed as a module - Any code inside
<module>will be parsed as a module, if we can get away with the relevant parser change - Any code which is imported, e.g. via an
importstatement inside another module, or via aSystem.importcall in a script or module, will be parsed as a module
That basically leaves any code inside of or loaded by a non-type="module" <script> as script code, with all others module code.
+Dave to correct me if I got any of this wrong.
On Sun, Oct 19, 2014 at 7:48 PM, Domenic Denicola < domenic at domenicdenicola.com> wrote:
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Mark Volkmann
Can we say anything more concrete if we restrict the discussion to modern browsers as opposed to non-browser ES engines? Is it fair to say that in those environments a file will always be treated as a module if it is imported by another file that the browser has loaded?
Concretely, the plan of record (which may change as implementation realities descend upon us) is:
- Any code inside
<script type="module">will be parsed as a module- Any code inside
<module>will be parsed as a module, if we can get away with the relevant parser change
We cannot. Ian Hickson pointed out the compat/security problems with trying to introduce such a tag, and they are fatal. We discussed them here and IIRC no one had a workable answer. IIRC, the browser rules for skipping element content of unrecognized elements is not compatible with the rules for parsing the element content of the <module> tag. This difference would
make the web vulnerable to a new class of injection attacks. For all new standard tags, browsers that recognize these tags and browsers that do not must agree on when the element is done.
If anyone has a link to the prior discussion, please post.
From: Mark S. Miller [mailto:erights at google.com]
For all new standard tags, browsers that recognize these tags and browsers that do not must agree on when the element is done.
This can't be completely true, as <main> and <template> were introduced recently and definitely don't follow that guideline.
I do remember the discussion going much as you say, though.
On Sun, Oct 19, 2014 at 8:05 PM, Domenic Denicola < domenic at domenicdenicola.com> wrote:
From: Mark S. Miller [mailto:erights at google.com]
For all new standard tags, browsers that recognize these tags and browsers that do not must agree on when the element is done.
This can't be completely true, as
<main>and<template>were introduced recently and definitely don't follow that guideline.
That is very interesting then. Is there any discussion about why these are safe? Are they safe?
On Sun, Oct 19, 2014 at 2:23 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
wrote:
It is implementation dependent how it is determined whether an individual file will be parsed as a Script or as a Module.
Axel alluded to a possible HTML extension that could be used to distinguish modules from scripts. But, exactly how modules will be integrated into HTML is still under development.
You can imagine various ways that modules might be identified in a command line environment. for example
js script1.js -m mod1.js -m mod2.js script2.js
so of us have argued that a module file extension might be useful in such environments:
js script1.js mod1.js mod2.js script2.js
FWIW, traceur has to use --script vs --module on the command line and .module.js among files otherwise parsed as script.
You may recall that Yehuda Katz suggested on this group that a prefix might be used, script:file.js. To avoid long arguments about What Is a URL, I suggest a postfix string, file.js,script. Of course a file extension would be better. Many build tools use filenames and this issue puts practical work with ES6 at a disadvantage.
jjb
it is a module if:
a) it is imported using imperative form thru a loader (with we are still working out the details) b) it is imported using declarative form (ImportDeclaration) c) future <module> tag, or <script type="module"> (still to figure).
there is an exception for these rules. if you use a loader hook to load dynamic modules, but that's about it.
I agree that we should come to consensus on a file extension. The argument that "it is out of our jurisdiction" only makes sense to me if it is in some other group's jurisdiction. AFAICT, it is not. And consensus is needed, so let's proceed.
Suggestions? Is there any reason we should still limit ourselves to the traditional three characters? Are there any registries reliable enough to get a sense of possible conflicts, or how bad they may be? Once we choose an extension, what if anything should be done about correspondence with mime type?
IIRC, the extension ".jsm" was already proposed, but may have had fatal conflicts. To get the ball rolling, ".jsmod" ?
---------- Forwarded message ---------- From: Mark Miller <erights at gmail.com> To: John Barton <johnjbarton at google.com> Cc: es-discuss <es-discuss at mozilla.org>, Erik Arvidsson <
erik.arvidsson at gmail.com>
Date: Sun, 19 Oct 2014 21:26:27 -0700 Subject: Re: what makes a file a module? I agree that we should come to consensus on a file extension. The
argument that "it is out of our jurisdiction" only makes sense to me if it is in some other group's jurisdiction. AFAICT, it is not. And consensus is needed, so let's proceed.
Suggestions? Is there any reason we should still limit ourselves to the traditional
three characters?
Are there any registries reliable enough to get a sense of possible
conflicts, or how bad they may be?
Once we choose an extension, what if anything should be done about
correspondence with mime type?
IIRC, the extension ".jsm" was already proposed, but may have had fatal
conflicts. To get the ball rolling, ".jsmod" ?
Or maybe, less obtrusively, ".m.js" or ".mod.js"? It would still be possible to tell them apart near instantly, while tooling can still often rely on the ".js" extension. Syntax highlighters won't really have to change.
The multiple extension format is already somewhat commonplace, especially with tarballs. PortableApps.com uses ".paf.exe" to denote their application installers while still allowing them to be run standalone by Windows.
On Sun, Oct 19, 2014 at 8:43 PM, John Barton <johnjbarton at google.com>
wrote:
On Sun, Oct 19, 2014 at 2:23 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
wrote:
It is implementation dependent how it is determined whether an
individual file will be parsed as a Script or as a Module.
Axel alluded to a possible HTML extension that could be used to
distinguish modules from scripts. But, exactly how modules will be integrated into HTML is still under development.
You can imagine various ways that modules might be identified in a
command line environment. for example
js script1.js -m mod1.js -m mod2.js script2.js
so of us have argued that a module file extension might be useful in
such environments:
js script1.js mod1.js mod2.js script2.js
FWIW, traceur has to use --script vs --module on the command line and .module.js among files otherwise parsed as script.
You may recall that Yehuda Katz suggested on this group that a prefix
might be used, script:file.js. To avoid long arguments about What Is a URL, I suggest a postfix string, file.js,script. Of course a file extension would be better. Many build tools use filenames and this issue puts practical work with ES6 at a disadvantage.
I plan to continue using ".js" for my modules. This distinction already exists in Node and AMD code and I've seen no need to differentiate my files.
I understand that module code is implicitly in strict mode. In an ES6 environment, what causes a .js file to be treated as a module? Does that happen automatically to all files that export at least one thing?