Re: Re: ModuleSpecifier: include .js or not?
This question has already been asked
https://mail.mozilla.org/pipermail/es-discuss/2015-February/041430.html
I prefer to follow the following rules:
File structure
```
root/
foo/
index.js
```
Export module
```js
export default foo class () {}
```
Import module
```js
import foo from './foo';
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ModuleSpecifier: include .js or not?
In Node.js you can either mention the file extension .js or omit it when you require a module. Which one is preferred for ES6 ModuleSpecifiers? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleSpecifier: include .js or not?
Some food for thought from a non-standard use-case. In GPSEE, we can require(module) - but we support both modules written in JavaScript, and modules written in C (technically, any compiled binary with the correct C API), or both. We dlload(module.so) (if present), then interpret module.js (if present) as part of the module loading procedure. So, from my POV, loading a module from script with the extension .js is not ideal. If you are going to assign meaning to the extension, you must think about what it means. In our case, it indicates the file type to load, and the implementation of the library is not relevant to the library user - only the API matters. And if you are only ever going to allow one extension type, then there is no point to typing .js on the end of every module name. In my opinion, the ModuleSpecifier should be fed the module name, and is it up to the loader to munge the filename (eg by adding .js) as it sees fit. Wes ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: include 'foo/index.js' or include 'foo'?
Doh... I really slipped on this one...
On Feb 6, 2015 3:21 AM, Isiah Meadows impinb...@gmail.com wrote:
The current spec being worked on to resolve this problem is at
http://whatwg.github.io/loader. It's still under construction, but it's
being written with browser and Node interop in mind.
From: John Barton johnjbar...@google.com
To: Glen Huang curvedm...@gmail.com
Cc: monolithed monolit...@gmail.com, es-discuss
es-discuss@mozilla.org
Date: Thu, 5 Feb 2015 07:53:47 -0800
Subject: Re: include 'foo/index.js' or include 'foo'?
The following solution has worked very well for us:
import './foo/index.js';
means resolve './foo/index.js' relative to the importing file.
All of the rest mean look up 'foo' in the developer's mapping of names,
replacing 'foo' with a path that is then used to resolve the import.
To be sure 'foo' 'foo/index' and 'foo/' would likely fail after lookup
since they don't name files.
(This kind of thing cannot be up to the host. If TC39 passes on
deciding, then developers will).
jjb
On Thu, Feb 5, 2015 at 5:01 AM, Glen Huang curvedm...@gmail.com wrote:
I believe this is out the scope of ecmascript. It’s up to the host to
determine how the paths are resolved.
See
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-hostnormalizemodulename
On Feb 5, 2015, at 8:51 PM, monolithed monolit...@gmail.com wrote:
I could not find an answer in the specification regarding the
following cases:
import './foo/index.js'
import 'foo/index.js'
import 'foo/index'
import 'foo'
import 'foo/'
Is there a difference?
Node.js lets create an 'index.js' file, which indicates the main
include file for a directory.
So if you call require('./foo'), both a 'foo.js' file as well as an
'foo/index.js' file will be considered, this goes for non-relative includes
as well.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: include 'foo/index.js' or include 'foo'?
1. I made a mistake sending the email initially.
2. I was referencing the spec for the future module loader.
3. I think you meant to hit Reply All.
On Feb 6, 2015 10:27 AM, John Barton johnjbar...@google.com wrote:
?
On Fri, Feb 6, 2015 at 12:24 AM, Isiah Meadows impinb...@gmail.com
wrote:
Doh... I really slipped on this one...
On Feb 6, 2015 3:21 AM, Isiah Meadows impinb...@gmail.com wrote:
The current spec being worked on to resolve this problem is at
http://whatwg.github.io/loader. It's still under construction, but it's
being written with browser and Node interop in mind.
From: John Barton johnjbar...@google.com
To: Glen Huang curvedm...@gmail.com
Cc: monolithed monolit...@gmail.com, es-discuss
es-discuss@mozilla.org
Date: Thu, 5 Feb 2015 07:53:47 -0800
Subject: Re: include 'foo/index.js' or include 'foo'?
The following solution has worked very well for us:
import './foo/index.js';
means resolve './foo/index.js' relative to the importing file.
All of the rest mean look up 'foo' in the developer's mapping of
names, replacing 'foo' with a path that is then used to resolve the import.
To be sure 'foo' 'foo/index' and 'foo/' would likely fail after
lookup since they don't name files.
(This kind of thing cannot be up to the host. If TC39 passes on
deciding, then developers will).
jjb
On Thu, Feb 5, 2015 at 5:01 AM, Glen Huang curvedm...@gmail.com
wrote:
I believe this is out the scope of ecmascript. It’s up to the host
to determine how the paths are resolved.
See
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-hostnormalizemodulename
On Feb 5, 2015, at 8:51 PM, monolithed monolit...@gmail.com
wrote:
I could not find an answer in the specification regarding the
following cases:
import './foo/index.js'
import 'foo/index.js'
import 'foo/index'
import 'foo'
import 'foo/'
Is there a difference?
Node.js lets create an 'index.js' file, which indicates the main
include file for a directory.
So if you call require('./foo'), both a 'foo.js' file as well as an
'foo/index.js' file will be considered, this goes for non-relative includes
as well.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
include 'foo/index.js' or include 'foo'?
I could not find an answer in the specification regarding the following
cases:
import './foo/index.js'
import 'foo/index.js'
import 'foo/index'
import 'foo'
import 'foo/'
Is there a difference?
Node.js lets create an 'index.js' file, which indicates the main include
file for a directory.
So if you call require('./foo'), both a 'foo.js' file as well as an
'foo/index.js' file will be considered, this goes for non-relative includes
as well.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: include 'foo/index.js' or include 'foo'?
```js import './foo/index.js'; import 'foo/index.js'; import 'foo/index'; import 'foo'; import 'foo/‘; ``` ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: include 'foo/index.js' or include 'foo'?
I believe this is out the scope of ecmascript. It’s up to the host to determine
how the paths are resolved.
See
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-hostnormalizemodulename
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-hostnormalizemodulename
On Feb 5, 2015, at 8:51 PM, monolithed monolit...@gmail.com
mailto:monolit...@gmail.com wrote:
I could not find an answer in the specification regarding the following cases:
import './foo/index.js'
import 'foo/index.js'
import 'foo/index'
import 'foo'
import 'foo/'
Is there a difference?
Node.js lets create an 'index.js' file, which indicates the main include file
for a directory.
So if you call require('./foo'), both a 'foo.js' file as well as an
'foo/index.js' file will be considered, this goes for non-relative includes
as well.
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: include 'foo/index.js' or include 'foo'?
The following solution has worked very well for us:
import './foo/index.js';
means resolve './foo/index.js' relative to the importing file.
All of the rest mean look up 'foo' in the developer's mapping of names,
replacing 'foo' with a path that is then used to resolve the import.
To be sure 'foo' 'foo/index' and 'foo/' would likely fail after lookup
since they don't name files.
(This kind of thing cannot be up to the host. If TC39 passes on deciding,
then developers will).
jjb
On Thu, Feb 5, 2015 at 5:01 AM, Glen Huang curvedm...@gmail.com wrote:
I believe this is out the scope of ecmascript. It’s up to the host to
determine how the paths are resolved.
See
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-hostnormalizemodulename
On Feb 5, 2015, at 8:51 PM, monolithed monolit...@gmail.com wrote:
I could not find an answer in the specification regarding the following
cases:
import './foo/index.js'
import 'foo/index.js'
import 'foo/index'
import 'foo'
import 'foo/'
Is there a difference?
Node.js lets create an 'index.js' file, which indicates the main include
file for a directory.
So if you call require('./foo'), both a 'foo.js' file as well as an
'foo/index.js' file will be considered, this goes for non-relative includes
as well.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
include
In the module system we issue
import {foo} from 'foo';
and the Loader computes an address, say foo.js, fetches the resource and
compiles it. If the content of foo.js has no dependencies, it is evaluated,
then the importer is evaluated. Yay!
Now suppose that foo.js defines a global value. Oh bad sure, but sometimes
you have to play cards you are dealt. We still depend upon foo.js, bad or
not bad.
In the current module system we have to abandon ship. In our importer we
need to:
// WARNING pre-load foo.js somehow!
Now imagine if we could issue
include 'foo';
and the Loader computes an address, say foo.js,fetches the resource and
compiles it. Since the content has no dependencies, it is evaluated, then
the importer is evaluated. Yay!
On now back to preloading somehow,
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: include
Why not:
import {} from 'foo';
or
import * as f from 'foo';
This is assuming that there are no other desired exports -- if there
are, then the case is even easier.
Sam
On Mon, Jul 14, 2014 at 8:37 PM, John Barton johnjbar...@google.com wrote:
In the module system we issue
import {foo} from 'foo';
and the Loader computes an address, say foo.js, fetches the resource and
compiles it. If the content of foo.js has no dependencies, it is evaluated,
then the importer is evaluated. Yay!
Now suppose that foo.js defines a global value. Oh bad sure, but sometimes
you have to play cards you are dealt. We still depend upon foo.js, bad or
not bad.
In the current module system we have to abandon ship. In our importer we
need to:
// WARNING pre-load foo.js somehow!
Now imagine if we could issue
include 'foo';
and the Loader computes an address, say foo.js,fetches the resource and
compiles it. Since the content has no dependencies, it is evaluated, then
the importer is evaluated. Yay!
On now back to preloading somehow,
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: include
There is also:
import foo;
Yehuda Katz
(ph) 718.877.1325
On Mon, Jul 14, 2014 at 6:24 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
Why not:
import {} from 'foo';
or
import * as f from 'foo';
This is assuming that there are no other desired exports -- if there
are, then the case is even easier.
Sam
On Mon, Jul 14, 2014 at 8:37 PM, John Barton johnjbar...@google.com
wrote:
In the module system we issue
import {foo} from 'foo';
and the Loader computes an address, say foo.js, fetches the resource and
compiles it. If the content of foo.js has no dependencies, it is
evaluated,
then the importer is evaluated. Yay!
Now suppose that foo.js defines a global value. Oh bad sure, but
sometimes
you have to play cards you are dealt. We still depend upon foo.js, bad or
not bad.
In the current module system we have to abandon ship. In our importer we
need to:
// WARNING pre-load foo.js somehow!
Now imagine if we could issue
include 'foo';
and the Loader computes an address, say foo.js,fetches the resource and
compiles it. Since the content has no dependencies, it is evaluated, then
the importer is evaluated. Yay!
On now back to preloading somehow,
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: include
Sorry, I was imagining a specific scenario without giving the specifics:
include 'foo'; // foo is conventional JS, not a module
I have written on global in a module, it works ok, but the goal was
specifically to mutate global with code written in a module.
Here I have given code, designed to be loaded with a script tag or
included with require() in node. When I try to use say
import foo;
I get things like
SyntaxError: In strict mode code, functions can only be declared at top
level or immediately within another function.
You could say, oh this is just legacy code, but boy we've burnt a lot of
energy on legacy modules maybe a small bit can be invested in legacy
scripts.
jjb
On Mon, Jul 14, 2014 at 6:39 PM, Yehuda Katz wyc...@gmail.com wrote:
There is also:
import foo;
Yehuda Katz
(ph) 718.877.1325
On Mon, Jul 14, 2014 at 6:24 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
Why not:
import {} from 'foo';
or
import * as f from 'foo';
This is assuming that there are no other desired exports -- if there
are, then the case is even easier.
Sam
On Mon, Jul 14, 2014 at 8:37 PM, John Barton johnjbar...@google.com
wrote:
In the module system we issue
import {foo} from 'foo';
and the Loader computes an address, say foo.js, fetches the resource and
compiles it. If the content of foo.js has no dependencies, it is
evaluated,
then the importer is evaluated. Yay!
Now suppose that foo.js defines a global value. Oh bad sure, but
sometimes
you have to play cards you are dealt. We still depend upon foo.js, bad
or
not bad.
In the current module system we have to abandon ship. In our importer we
need to:
// WARNING pre-load foo.js somehow!
Now imagine if we could issue
include 'foo';
and the Loader computes an address, say foo.js,fetches the resource and
compiles it. Since the content has no dependencies, it is evaluated,
then
the importer is evaluated. Yay!
On now back to preloading somehow,
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: include
You could imagine a loader plugin that enabled:
import legacy:foo;
Which would evaluate the module in a script context.
Yehuda Katz
(ph) 718.877.1325
On Mon, Jul 14, 2014 at 9:20 PM, John Barton johnjbar...@google.com wrote:
Sorry, I was imagining a specific scenario without giving the specifics:
include 'foo'; // foo is conventional JS, not a module
I have written on global in a module, it works ok, but the goal was
specifically to mutate global with code written in a module.
Here I have given code, designed to be loaded with a script tag or
included with require() in node. When I try to use say
import foo;
I get things like
SyntaxError: In strict mode code, functions can only be declared at top
level or immediately within another function.
You could say, oh this is just legacy code, but boy we've burnt a lot of
energy on legacy modules maybe a small bit can be invested in legacy
scripts.
jjb
On Mon, Jul 14, 2014 at 6:39 PM, Yehuda Katz wyc...@gmail.com wrote:
There is also:
import foo;
Yehuda Katz
(ph) 718.877.1325
On Mon, Jul 14, 2014 at 6:24 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
Why not:
import {} from 'foo';
or
import * as f from 'foo';
This is assuming that there are no other desired exports -- if there
are, then the case is even easier.
Sam
On Mon, Jul 14, 2014 at 8:37 PM, John Barton johnjbar...@google.com
wrote:
In the module system we issue
import {foo} from 'foo';
and the Loader computes an address, say foo.js, fetches the resource
and
compiles it. If the content of foo.js has no dependencies, it is
evaluated,
then the importer is evaluated. Yay!
Now suppose that foo.js defines a global value. Oh bad sure, but
sometimes
you have to play cards you are dealt. We still depend upon foo.js, bad
or
not bad.
In the current module system we have to abandon ship. In our importer
we
need to:
// WARNING pre-load foo.js somehow!
Now imagine if we could issue
include 'foo';
and the Loader computes an address, say foo.js,fetches the resource and
compiles it. Since the content has no dependencies, it is evaluated,
then
the importer is evaluated. Yay!
On now back to preloading somehow,
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
