what makes a file a module?

[Mark Volkmann]

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?

[Erik Arvidsson]

A file that is imported is treated as a module. That's it.

Post by Mark Volkmann
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?
--
R. Mark Volkmann
Object Computing, Inc.
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141019/9d58f0a4/attachment.html>

[Rick Waldron]

On Sun, Oct 19, 2014 at 1:59 PM, Erik Arvidsson <erik.arvidsson at gmail.com>

Post by Erik Arvidsson
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.

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141019/ca2b107d/attachment.html>

[Allen Wirfs-Brock]

Post by Erik Arvidsson
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.

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

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141019/c55e1abe/attachment.html>

[Mark Volkmann]

On Sun, Oct 19, 2014 at 4:23 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>

Post by Allen Wirfs-Brock
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.

[Allen Wirfs-Brock]

Post by Allen Wirfs-Brock
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.

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141019/c7c8778e/attachment.html>

[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?

On Sun, Oct 19, 2014 at 4:47 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>

Post by Mark Volkmann

Post by Allen Wirfs-Brock
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.
Allen

[Allen Wirfs-Brock]

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.

Allen

[Domenic Denicola]

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 `import` statement inside another module, or via a `System.import` call 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.

[Mark S. Miller]

On Sun, Oct 19, 2014 at 7:48 PM, Domenic Denicola <

Post by Domenic Denicola
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Mark Volkmann

Post by 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
- 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.

Post by Domenic Denicola
- Any code which is imported, e.g. via an `import` statement inside
another module, or via a `System.import` call 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.
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

[Domenic Denicola]

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.

[Mark S. Miller]

On Sun, Oct 19, 2014 at 8:05 PM, Domenic Denicola <

Post by Domenic Denicola
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?

Post by Domenic Denicola
I do remember the discussion going much as you say, though.

[Caridy Patino]

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.

/caridy

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?

Post by Allen Wirfs-Brock

Post by Allen Wirfs-Brock

Post by Allen Wirfs-Brock
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.
Allen

--
R. Mark Volkmann
Object Computing, Inc.
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141019/ec55456b/attachment.html>

[John Barton]

On Sun, Oct 19, 2014 at 2:23 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>

Post by Allen Wirfs-Brock
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141019/9812ce6f/attachment.html>

[Mark Miller]

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" ?

Post by John Barton
On Sun, Oct 19, 2014 at 2:23 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>

Post by Allen Wirfs-Brock
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
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
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

[Domenic Denicola]

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.

[Axel Rauschmayer]

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.

Post by Mark Volkmann
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?
--
R. Mark Volkmann
Object Computing, Inc.
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

--
Dr. Axel Rauschmayer
axel at rauschma.de
rauschma.de



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141019/37f31d72/attachment.html>

[Isiah Meadows]

---------- 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>

Post by John Barton
On Sun, Oct 19, 2014 at 2:23 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>

Post by Allen Wirfs-Brock
It is implementation dependent how it is determined whether an

individual file will be parsed as a Script or as a Module.

Post by John Barton

Post by Allen Wirfs-Brock
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.

Post by John Barton

Post by Allen Wirfs-Brock
You can imagine various ways that modules might be identified in a

command line environment. for example

Post by John Barton

Post by Allen Wirfs-Brock
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
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.

Post by John Barton
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.

Post by John Barton
jjb
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141020/d615795f/attachment.html>