Common config spec

Showing 1-14 of 14 messages
Common config spec James Burke 1/17/12 4:59 PM
Following up from the result of some discussions last year, I would
like to start a draft spec for some common configuration values
accepted by loaders. Here is my shot at this:

https://gist.github.com/1630091

Some things to note:

* map is specified, which behaves similar to Dojo's packageMap, but
can be applied to packages or paths.
* config: is an option under paths and packages. I'm not sure it
should be scoped more to allow passing individual modules in a package
config values.

config also implies allowing access to the config in a module via a
new property that would be documented in the AMD spec:
module.config().

This is just to get the ball rolling. Feedback is desired. Once we
have a chance to chew it over, I can put it on the AMD wiki. I can do
that sooner if you prefer, but figured I would wait to see if we might
be able to agree on some values first.

The need for at least the standardized config config: I tried to use
the dojo/has plugin in the requirejs optimizer, but there was not a
way for me to pass dojo/has a configuration to use during the build of
what has tests should be considered true/false.

So the hope is that by standardizing configuration passing it would be
possible to more easily reuse some of these plugins in different build
systems.

James

Re: Common config spec James Burke 1/17/12 5:04 PM
On Tue, Jan 17, 2012 at 4:59 PM, James Burke <jrb...@gmail.com> wrote:
> https://gist.github.com/1630091

> * config: is an option under paths and packages. I'm not sure it
> should be scoped more to allow passing individual modules in a package
> config values.

Maybe config is just a top-level value, not under paths and packages,
with absolute module IDs as property names and config objects as
values, and the config is only passed to that specific module ID.

James

Re: [amd-implement] Re: Common config spec Richard Backhouse 1/17/12 5:20 PM

Having config object at the top level makes more sense to me.

Richard

Re: Common config spec Ben Hockey 1/18/12 7:43 PM
(from packages)

String: The module prefix uses "package rules". The prefix can only be the first segment of an absolute module ID.

 - what are "package rules"?
 - what is the prefix? 
 - why can prefix only be the first segment of the id?  maybe that will be evident when i understand what prefix means.

thanks,

ben...
Re: [amd-implement] Re: Common config spec James Burke 1/23/12 2:06 PM

I rewrote that section to try to clarify, including an example. If
that does not help, let me know:

https://gist.github.com/1630091

Also, based on Richard's feedback, I moved the 'config' section to its
own top level section, it is  no longer under paths and packages.

James

Re: [amd-implement] Re: Common config spec Ben Hockey 1/24/12 8:01 AM
can you clarify the reason that in a packageConfig and in a map "only the first segment of a module prefix is allowed"?  i'm not sure i'd ever try to do something other than this (and i don't know if any of the loaders support something other than this) but is there a limitation that means its impossible/impractical to do this or is there some other reason?  i'm guessing its because its just not practical to do a lookup for every segment in a path to try and find a package that matches.

thanks,

ben...
Re: [amd-implement] Re: Common config spec James Burke 1/24/12 5:15 PM

I believe the packages thing falls out of CommonJS packages where they
only use the first segment of the ID as the "package name". As for
map, I'm picking this up from the dojo packageMap, and I suspect that
it just uses the first segment to match the expected package behavior
from CommonJS stuff.

It does also make lookup easier. Although 'paths' allows multiple
segment prefix, we could support that for the other settings. Although
it seems common for package to be "top level" and be a complete unit,
and for doing a mapping, seems like it would also be a first segment
kind of thing. I'm having trouble thinking of a case that would be
helped by having a multiple segment prefix for packages and map. I can
see paths, for mapping out a specific file in a 'package', but not for
the others.

James

Re: [amd-implement] Re: Common config spec Rawld 1/31/12 12:55 PM
On 01/23/2012 02:06 PM, James Burke wrote:
> [snip]

> I rewrote that section to try to clarify, including an example. If
> that does not help, let me know:
>
> https://gist.github.com/1630091
>

Thanks for working on this James!

This looks good to me. The only thing that gives me pause is the
module.config business.

I would prefer to make module.config a mutable object instead of a method:

The first time a the pseudo module "module" is provided, module.config
is set to the value as given by the config property for that module (if
any), or an empty object otherwise. From there, module.config can be
mutated by module code or completely replaced by providing another
config property for that module.

--Rawld


Re: [amd-implement] Re: Common config spec Rawld 1/31/12 12:58 PM
On 01/24/2012 05:15 PM, James Burke wrote:
> On Tue, Jan 24, 2012 at 8:01 AM, Ben Hockey<neonst...@gmail.com>  wrote:
>> can you clarify the reason that in a packageConfig and in a map "only the
>> first segment of a module prefix is allowed"?  i'm not sure i'd ever try to
>> do something other than this (and i don't know if any of the loaders support
>> something other than this) but is there a limitation that means its
>> impossible/impractical to do this or is there some other reason?  i'm
>> guessing its because its just not practical to do a lookup for every segment
>> in a path to try and find a package that matches.
> I believe the packages thing falls out of CommonJS packages where they
> only use the first segment of the ID as the "package name". As for
> map, I'm picking this up from the dojo packageMap, and I suspect that
> it just uses the first segment to match the expected package behavior
> from CommonJS stuff.
Re dojo pacakgeMap, exactly. I view the future for significant
applications as using several packages ("libraries" in other
communities), and the only problem map is intended to solve is clashing
package names.

Simple applications don't need to worry about any of this.

--Rawld

Re: [amd-implement] Re: Common config spec James Burke 2/1/12 6:54 PM
On Tue, Jan 31, 2012 at 12:55 PM, Rawld <rg...@altoviso.com> wrote:
> This looks good to me. The only thing that gives me pause is the
> module.config business.
>
> I would prefer to make module.config a mutable object instead of a method:
>
> The first time a the pseudo module "module" is provided, module.config is
> set to the value as given by the config property for that module (if any),
> or an empty object otherwise. From there, module.config can be mutated by
> module code or completely replaced by providing another config property for
> that module.

I updated the gist to be a mutable object. Note that only the module
that matches the module ID has access to the config object, unless
that module decides to explicitly pass it to some other module.

I also added this bit at the beginning:

"An AMD loader is not **required** to implement all of these
configuration values, but if it does provide a capability that is
satisfied by these configuration values, it should use these
configuration values and structures."

I added this because there are some specialized loaders, like almond,
that do not need to provide all of these config options. Also, I'm
thinking of removing packages support in RequireJS 1.1, and instead
rely on volo to create adapter modules that load the package's main
module, but I'm still working out the details, if it makes sense,
particularly when working with a package in its own repo, running
tests.

I would like to hear from John Hann if these make sense, particularly
since I based config on some things he suggested, and I'll look at
putting this in draft form on the amdjs wiki.

James

Re: Common config spec James Burke 4/27/12 10:57 AM
On Tue, Jan 17, 2012 at 4:59 PM, James Burke <jrb...@gmail.com> wrote:
> Following up from the result of some discussions last year, I would
> like to start a draft spec for some common configuration values
> accepted by loaders. Here is my shot at this:
>
> https://gist.github.com/1630091

Follow up on this: I have the "config" one working in a requirejs.next
branch, and I'm looking at the "map" property.

I'm writing a unit test for it, and notice that it really is not
related to packages or paths config -- those configs are about setting
up paths related to a module ID.

map is more mapping the first segment of an ID to another ID. So what
about breaking it out as its own config, as a sibling to "paths" and
"packages" instead of being under "paths" and "packages"?

Otherwise, I think it is confusing: the map is wedged in with config
items that are really path segments, not IDs. And when under paths, I
think it also gets confusing that map is only for mapping the first
segment of an ID instead of the multiple path segments that show up
under paths -- there are two strings that look similar but have
different meanings right next to each other.

Rawld, I think this mostly impacts the dojo code as it is currently
the only one that has this kind of feature.

James
Re: Common config spec Ben Hockey 4/27/12 11:44 AM
On Friday, April 27, 2012 1:57:54 PM UTC-4, James Burke wrote:
I'm writing a unit test for it, and notice that it really is not
related to packages or paths config -- those configs are about setting
up paths related to a module ID.

map is more mapping the first segment of an ID to another ID. So what
about breaking it out as its own config, as a sibling to "paths" and
"packages" instead of being under "paths" and "packages"?

currently the way its implemented in dojo, you can have a separate map per package.  will you lose that ability?  this was the point of it being under the packages config - so that it was per package.

ben... 
Re: [amd-implement] Re: Common config spec James Burke 4/27/12 12:30 PM
I was thinking that it would still be keyed by module ID, so if a
module ID maps to a package, it would still apply:

{
    packages: {
        name: 'dojo',
        location: 'dojo/1.7.1',
        main:'main'
    },
    map: {
        'dojo': {
            'dijit': 'dijit171'
        }
    }
}

I think there are many projects that do not need any paths/packages
config, just a mapping for the occasional conflict. And maps deal with
ID-to-ID mappings, not ID-to-path mappings.

James
Re: [amd-implement] Re: Common config spec James Burke 4/28/12 2:05 PM
On Fri, Apr 27, 2012 at 12:30 PM, James Burke <jrb...@gmail.com> wrote:
> I think there are many projects that do not need any paths/packages
> config, just a mapping for the occasional conflict. And maps deal with
> ID-to-ID mappings, not ID-to-path mappings.

I was looking at supporting Dojo's 'alias' feature too, and I'm
wondering if it is just the same as map. I think it is, but I would
appreciate confirmation form Ben or Rawld.

If so, then I think the "map" config is just missing a way to say
"globally for all modules, use this mapping". I did an experiment by
using '*' to signify this. I think it holds together, example from a
test page:

{
    map: {
        '*': {
            'c': 'another/c'
        },
        'a': {
            c: 'c1'
        },
        'a/sub/one': {
            'c': 'c2',
            'c/sub': 'another/c/sub'
        }
    }
}

Most specific rule wins with "*" being the least specific if nothing
else matched.

In addition, more than one segment of the ID to match, vs what is
currently in that gist. I did this in particular so that someone could
map 'dojo/text' to be just 'text' (the reverse example in the dojo
docs about alias).

So with the above config the translation to the mapped modules IDs
looks like the following. Any paths/packages config would apply to the
mapped module ID:

//in module 'b'
require('c') -> require('another/c')
require('c/sub') -> require('another/c/sub')

//in module 'a'
require('c') -> require('c1')
require('c/sub') -> require('c1/sub')

//in module 'a/sub/one'
require('c') -> require('c2')
require('c/sub') -> require('another/c/sub')

I like this since it gives both the alias and packageMap concept from
dojo in one config option, although I could be missing something.

James