Re: include 'foo/index.js' or include 'foo'?

[Isiah Meadows]

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"  wrote:

> ?
>
> On Fri, Feb 6, 2015 at 12:24 AM, Isiah Meadows 
> wrote:
>
>> Doh... I really slipped on this one...
>>
>> On Feb 6, 2015 3:21 AM, "Isiah Meadows"  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 
>> > > To: Glen Huang 
>> > > Cc: monolithed , 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 
>> 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 
>> 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'?

[Isiah Meadows]

Doh... I really slipped on this one...

On Feb 6, 2015 3:21 AM, "Isiah Meadows"  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 
> > To: Glen Huang 
> > Cc: monolithed , 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  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  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'?

[John Barton]

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

[Glen Huang]

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

Re: Re: include 'foo/index.js' or include 'foo'?

[monolithed]

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

[Yehuda Katz]

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

Re: include

[John Barton]

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 

Re: include

[Yehuda Katz]

There is also:

import "foo";

Yehuda Katz
(ph) 718.877.1325


On Mon, Jul 14, 2014 at 6:24 PM, Sam Tobin-Hochstadt 
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 
> 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

[Sam Tobin-Hochstadt]

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