that was already discussed on the list. The changes from that draft:
* The map config is now its own config, not nested under paths or
packages, and it allows for a * config, and use of any module prefix.
* paths allows support for array values instead of strings, if the
loader supports fallback/failover loading.
We can take the DRAFT off if this seems generally acceptable and/or
there are more loaders that confirm they implement them. Right now
requirejs supports all of them.
Note that they are optional. A loader does not have to provide them or
can only choose to provide a subset. The main point is for us to
standardize on some for basic interop, if the loaders provide similar
functionality.
One that I did not specify, but have found very welcome in the
requirejs community is "shim":
but given that it is for helping legacy, non-AMD modules to
participate in AMD loading, I did not think it was appropriate to put
in the list, unless I hear from other AMD loader implementers that
they would want to support it too.
but it seems you're saying this is not how it works now.
it's also still unclear if the spec supports the use case i asked about at https://groups.google.com/d/msg/amd-implement/_vt4K62no4M/uxbXd4afWXUJ - the ability to do wholesale mapping per package is critical and is the primary use case supported by dojo's pacakgeMap. i would hate to have to list out every module in every package in order to get them properly mapped. i get the impression from the spec that the mapping is only supposed to happen per module id. for example with the following map
map: { pkgA: { // a map of module id prefixes to be remapped for any modules mapped into the pkgA prefix/package foo: "foo1.2" }
}
if the pkgA module depends on "foo", i expect it will get "foo1.2". if pkgA/moduleX depends on "foo", what should i see? i *think* that the spec allows for it to be "foo1.2" but i'm uncertain because it doesn't say so explicitly and every example i've seen (including requirejs tests) explicitly map the specific module being used but don't demonstrate what should happen for modules that share the same prefix. an example, if https://github.com/jrburke/requirejs/blob/2.0.4/tests/mapConfig/mapCo... required "a/sub" and that module had a dependency on "c", will it get "c" or "c1" or something else? i hope it gets "c1".
if we agree with how this should work then i'd like to see something in the spec that more clearly says that all modules that have a prefix that matches a prefix in the map, the dependencies will be remapped according to the map config.
> -----Original Message-----
> From: amd-implement@googlegroups.com [mailto:amd-
> implement@googlegroups.com] On Behalf Of Ben Hockey
> Sent: Monday, July 16, 2012 12:49 PM
> To: amd-implement@googlegroups.com
> Subject: [amd-implement] Re: Common configuration draft
> i'm confused...
> * The map config is now its own config, not nested under paths or
> packages...
It is still nested under packages...look just above in the spec. And I think that is where the equivalent of dojo's packageMap takes place and answers the questions below.
Let me know if I'm not understanding your observation.
> but it seems you're saying this is not how it works now.
> it's also still unclear if the spec supports the use case i asked about at
> https://groups.google.com/d/msg/amd- > implement/_vt4K62no4M/uxbXd4afWXUJ - the ability to do wholesale mapping
> per package is critical and is the primary use case supported by dojo's
> pacakgeMap. i would hate to have to list out every module in every package in
> order to get them properly mapped. i get the impression from the spec that the
> mapping is only supposed to happen per module id. for example with the
> following map
> map: {
> pkgA: {
> // a map of module id prefixes to be remapped for any modules mapped into
> the pkgA prefix/package
> foo: "foo1.2"
> }
> }
> if the pkgA module depends on "foo", i expect it will get "foo1.2". if
> pkgA/moduleX depends on "foo", what should i see? i *think* that the spec
> allows for it to be "foo1.2" but i'm uncertain because it doesn't say so explicitly
> and every example i've seen (including requirejs tests) explicitly map the specific
> module being used but don't demonstrate what should happen for modules that
> share the same prefix. an example, if
> https://github.com/jrburke/requirejs/blob/2.0.4/tests/mapConfig/mapCo... > tests.js required "a/sub" and that module had a dependency on "c", will it get
> "c" or "c1" or something else? i hope it gets "c1".
> if we agree with how this should work then i'd like to see something in the spec
> that more clearly says that all modules that have a prefix that matches a prefix in
> the map, the dependencies will be remapped according to the map config.
> -----Original Message-----
> From: amd-implement@googlegroups.com [mailto:amd-
> implement@googlegroups.com] On Behalf Of Ben Hockey
> Sent: Monday, July 16, 2012 12:49 PM
> for example with the following map
> map: {
> pkgA: {
> // a map of module id prefixes to be remapped for any modules mapped into
> the pkgA prefix/package
> foo: "foo1.2"
> }
> }
> if the pkgA module depends on "foo", i expect it will get "foo1.2". if
> pkgA/moduleX depends on "foo", what should i see? i *think* that the spec
> allows for it to be "foo1.2" but i'm uncertain because it doesn't say so explicitly
> and every example i've seen (including requirejs tests) explicitly map the specific
> module being used but don't demonstrate what should happen for modules that
> share the same prefix. an example, if
> https://github.com/jrburke/requirejs/blob/2.0.4/tests/mapConfig/mapCo... > tests.js required "a/sub" and that module had a dependency on "c", will it get
> "c" or "c1" or something else? i hope it gets "c1".
I understand the above map to say the module "pkgA"--and only that single module--will map the dependency "foo" in pkgA's deps vector to "foo1.2".
If pkgA is in fact a package and I want and foo/* dependency within any pkgA module to map to foo1.2, then I'd write the config as follows:
> if we agree with how this should work then i'd like to see something in the spec
> that more clearly says that all modules that have a prefix that matches a prefix in
> the map, the dependencies will be remapped according to the map config.
So, as I understand the spec, map is defined as follows:
map:(module-id or "*") --> (map:(prefix) --> replacement)
> It is still nested under packages...look just above in the spec. And I > think that is where the equivalent of dojo's packageMap takes place and > answers the questions below.
we need james to clarify his intentions with the changes he made when translating the spec from the gist to the wiki.
based on the comments in james' initial post on this thread, my concern is that the piece about map in the package section of the wiki is a remnant that he may have intended to remove. it's hard to say for certain because i'm trying to piece this together based on comments here, the spec in the wiki, the spec in the gist and all our previous discussion based on the content in the gist.
the way that map is described in the wiki, it doesn't really look like there is an intention for it to be used under the config for a package - maybe i'm wrong.
the other part that needs clarification too is whether the values to be remapped represent module ids or prefixes. eg: map: { pkgA: { foo: "foo1.2" }
}
if pkgA depends on "foo/bar" should it get "foo1.2/bar"?
i know how i would like all of this to work but i don't want to make assumptions based on how i'd like it to work. i don't see these clearly spelled out in the spec and i can see that it would be easy for different people to make different interpretations. hopefully we can avoid some frustration later by clarifying this now.
* I meant to remove map from the package area, bad copy paste. Map is its
own config section.
* map in requirejs is similar to paths: it I applied to to any module ID
prefix match, so it should meet your use case concern.
I apologize for not scrubbing the text better. I will update that draft
with the above, but it may take a day or so.
> but it seems you're saying this is not how it works now.
> it's also still unclear if the spec supports the use case i asked about at
> https://groups.google.com/d/msg/amd-implement/_vt4K62no4M/uxbXd4afWXUJ -
> the ability to do wholesale mapping per package is critical and is the
> primary use case supported by dojo's pacakgeMap. i would hate to have to
> list out every module in every package in order to get them properly
> mapped. i get the impression from the spec that the mapping is only
> supposed to happen per module id. for example with the following map
> map: {
> pkgA: {
> // a map of module id prefixes to be remapped for any modules mapped
> into the pkgA prefix/package
> foo: "foo1.2"
> }
> }
> if the pkgA module depends on "foo", i expect it will get "foo1.2". if
> pkgA/moduleX depends on "foo", what should i see? i *think* that the spec
> allows for it to be "foo1.2" but i'm uncertain because it doesn't say so
> explicitly and every example i've seen (including requirejs tests)
> explicitly map the specific module being used but don't demonstrate what
> should happen for modules that share the same prefix. an example, if
> https://github.com/jrburke/requirejs/blob/2.0.4/tests/mapConfig/mapCo... "a/sub" and that module had a dependency on "c", will it get "c"
> or "c1" or something else? i hope it gets "c1".
> if we agree with how this should work then i'd like to see something in
> the spec that more clearly says that all modules that have a prefix that
> matches a prefix in the map, the dependencies will be remapped according to
> the map config.
> -----Original Message-----
> From: amd-implement@googlegroups.com [mailto:amd-
> implement@googlegroups.com] On Behalf Of James Burke
> Sent: Montag, 16. Juli 2012 17:45
> To: amd-implement@googlegroups.com
> Subject: [amd-implement] Re: Common configuration draft
> Away from computer, but two notes:
> * I meant to remove map from the package area, bad copy paste. Map is its own
> config section.
> * map in requirejs is similar to paths: it I applied to to any module ID prefix
> match, so it should meet your use case concern.
> I apologize for not scrubbing the text better. I will update that draft with the
> above, but it may take a day or so.
On Mon, Jul 16, 2012 at 5:44 PM, James Burke <jrbu...@gmail.com> wrote:
> * I meant to remove map from the package area, bad copy paste. Map is its
> own config section.
It is now removed from the wiki page.
> * map in requirejs is similar to paths: it I applied to to any module ID
> prefix match, so it should meet your use case concern.
The map section has some text about this already, and an example.
Ben, if you think that section could be worded better, I'm open to
ideas. And of course if I completely misread your concern, clue me in.
:)
foo, foo1.2 and foo1.0 are module ID's and not module ID prefixes correct ?
Also, this is directed to James. Are you supporting Map Configs in r.js ? For my optimizer it has become quite involved on how to tackle the issue of the multiple modules defining themselves with the same id within the same delivered javascript stream.
> On Mon, Jul 16, 2012 at 5:44 PM, James Burke <jrbu...@gmail.com> wrote:
>> * I meant to remove map from the package area, bad copy paste. Map is its
>> own config section.
> It is now removed from the wiki page.
>> * map in requirejs is similar to paths: it I applied to to any module ID
>> prefix match, so it should meet your use case concern.
> The map section has some text about this already, and an example.
> Ben, if you think that section could be worded better, I'm open to
> ideas. And of course if I completely misread your concern, clue me in.
> :)
> foo, foo1.2 and foo1.0 are module ID's and not module ID prefixes correct ?
Ah, I treat them as module ID prefixes. That makes it more fun doesn't
it? :) I think it makes sense though, particularly for cjs-type
"packages". If someone asks for "foo/helper", seems like that should
translate to "foo1.0/helper" for oldmodule.
I need to work up some tests to include in the amdjs test set for this
common config now that we have a few folks implementing them. I'll try
to get it done next week. In the meantime, here are the tests I use in
requirejs:
The r.js optimizer does builds and places them in the "built" folder
in there as part of its unit tests, if you wonder where they come
from. The r.js map build tests start here and are their names start
with "map":
> Also, this is directed to James. Are you supporting Map Configs in r.js ?
> For my optimizer it has become quite involved on how to tackle the issue of
> the multiple modules defining themselves with the same id within the same
> delivered javascript stream.
I do support them in r.js, at least to the extent that the above tests
pass. If you have a tricky test case though, I am interested to see
it.
> On Tue, Sep 4, 2012 at 6:05 AM, Richard Backhouse
> <richardabackho...@gmail.com> wrote:
>> I'm in the process of implementing the Map Config support and wanted to
>> double check on something.
>> The spec states :
>> " Object. Specifies for a given module ID prefix, what module ID to use in
>> place of another module ID"
>> I just want to be sure that we are talking specifically about "module ID"
>> and not "module ID prefix" for the values in the mapEntry. For example
>> foo, foo1.2 and foo1.0 are module ID's and not module ID prefixes correct ?
> Ah, I treat them as module ID prefixes. That makes it more fun doesn't
> it? :) I think it makes sense though, particularly for cjs-type
> "packages". If someone asks for "foo/helper", seems like that should
> translate to "foo1.0/helper" for oldmodule.
> I need to work up some tests to include in the amdjs test set for this
> common config now that we have a few folks implementing them. I'll try
> to get it done next week. In the meantime, here are the tests I use in
> requirejs:
> The r.js optimizer does builds and places them in the "built" folder
> in there as part of its unit tests, if you wonder where they come
> from. The r.js map build tests start here and are their names start
> with "map":
>> Also, this is directed to James. Are you supporting Map Configs in r.js ?
>> For my optimizer it has become quite involved on how to tackle the issue of
>> the multiple modules defining themselves with the same id within the same
>> delivered javascript stream.
> I do support them in r.js, at least to the extent that the above tests
> pass. If you have a tricky test case though, I am interested to see
> it.
> James
Thanks for the clarification.
I think it would be best to modify the text in the spec to avoid confusion. Perhaps changing the wording to :
"Object. Specifies for a given module ID prefix, what module ID/prefix to use in place of another module ID/prefix"
What do you think ?
I took a look at the tests you have in requirejs and converted a few of them over to run in amdjs-tests. I took "mapConfig", "mapConfigStar" and "mapConfigStarAdapter". The others seemed to be more requirejs specific.
The "mapConfigStar" test has highlighted another gotcha (at least for me with the approach I have taken).
There is a map configuration of
'*': {
'c': 'another/c'
},
The 'another/c' module has a peer reference to a module called './minor' so the full mapped id for it would be 'another/minor'. At the moment the approach I have taken is not modify the ids that are written into the modules. That is they are in unmapped form. This results in multiple define calls with the same id. To handle this I add the matched mapping as an additonal parameter to the define call and that is used to better qualify the id of the module internally. With this approach I don't have to mess with the dependent list to modify the mapped id there too. This works for mapped ids and prefixes but the peer module has caused me problems. Looking at your built version of the "mapConfigStar" test I see that your code writes in the mapped ids. I'm curious to know if you also modify the modules dependency lists too for these mapped ids.
So it just dawned on me that the dependency list ids don't have to be modified as the only one that are affected as the relative ones and they don't need to be changed :-). I think my current approach is overdoing things.
> foo, foo1.2 and foo1.0 are module ID's and not module ID prefixes correct ?
> Ah, I treat them as module ID prefixes. That makes it more fun doesn't > it? :) I think it makes sense though, particularly for cjs-type > "packages". If someone asks for "foo/helper", seems like that should > translate to "foo1.0/helper" for oldmodule.
> I need to work up some tests to include in the amdjs test set for this > common config now that we have a few folks implementing them. I'll try > to get it done next week. In the meantime, here are the tests I use in > requirejs: > https://github.com/jrburke/requirejs/tree/master/tests/mapConfig
> The r.js optimizer does builds and places them in the "built" folder > in there as part of its unit tests, if you wonder where they come > from. The r.js map build tests start here and are their names start > with "map": > https://github.com/jrburke/r.js/blob/master/build/tests/builds.js#L998
> Also, this is directed to James. Are you supporting Map Configs in r.js ? > For my optimizer it has become quite involved on how to tackle the issue of > the multiple modules defining themselves with the same id within the same > delivered javascript stream.
> I do support them in r.js, at least to the extent that the above tests > pass. If you have a tricky test case though, I am interested to see > it.
> James
> Thanks for the clarification.
> I think it would be best to modify the text in the spec to avoid > confusion. Perhaps changing the wording to :
> "Object. Specifies for a given module ID prefix, what module ID/prefix to > use in place of another module ID/prefix"
> What do you think ?
> I took a look at the tests you have in requirejs and converted a few of > them over to run in amdjs-tests. I took "mapConfig", "mapConfigStar" and > "mapConfigStarAdapter". The others seemed to be more requirejs specific.
> The "mapConfigStar" test has highlighted another gotcha (at least for me > with the approach I have taken).
> There is a map configuration of
> '*': { > 'c': 'another/c' > },
> The 'another/c' module has a peer reference to a module called './minor' > so the full mapped id for it would be 'another/minor'. At the moment the > approach I have taken is not modify the ids that are written into the > modules. That is they are in unmapped form. This results in multiple define > calls with the same id. To handle this I add the matched mapping as an > additonal parameter to the define call and that is used to better qualify > the id of the module internally. With this approach I don't have to mess > with the dependent list to modify the mapped id there too. This works for > mapped ids and prefixes but the peer module has caused me problems. Looking > at your built version of the "mapConfigStar" test I see that your code > writes in the mapped ids. I'm curious to know if you also modify the > modules dependency lists too for these mapped ids.
After realizing my originally approach was overly complex and also doomed to failure I have ended up with a much simpler solution that passes the 3 mapConfig tests, "mapConfig", "mapConfigStar" and "mapConfigStarAdapter" :-)
James, if it helps I can fork the amdjs-tests repo and create a push request with these 3 tests I've added.
Richard
On 9/8/12 8:51 AM, Richard Backhouse wrote:
> So it just dawned on me that the dependency list ids don't have to be > modified as the only one that are affected as the relative ones and > they don't need to be changed :-). I think my current approach is > overdoing things.
> On Saturday, September 8, 2012 8:37:17 AM UTC-4, Richard Backhouse wrote:
> On 9/4/12 9:13 PM, James Burke wrote:
>> On Tue, Sep 4, 2012 at 6:05 AM, Richard Backhouse
>> <richardabackho...@gmail.com> <mailto:richardabackho...@gmail.com> wrote:
>>> I'm in the process of implementing the Map Config support and wanted to
>>> double check on something.
>>> The spec states :
>>> " Object. Specifies for a given module ID prefix, what module ID to use in
>>> place of another module ID"
>>> I just want to be sure that we are talking specifically about "module ID"
>>> and not "module ID prefix" for the values in the mapEntry. For example
>>> foo, foo1.2 and foo1.0 are module ID's and not module ID prefixes correct ?
>> Ah, I treat them as module ID prefixes. That makes it more fun doesn't
>> it? :) I think it makes sense though, particularly for cjs-type
>> "packages". If someone asks for "foo/helper", seems like that should
>> translate to "foo1.0/helper" for oldmodule.
>> I need to work up some tests to include in the amdjs test set for this
>> common config now that we have a few folks implementing them. I'll try
>> to get it done next week. In the meantime, here are the tests I use in
>> requirejs:
>> The r.js optimizer does builds and places them in the "built" folder
>> in there as part of its unit tests, if you wonder where they come
>> from. The r.js map build tests start here and are their names start
>> with "map":
>>> Also, this is directed to James. Are you supporting Map Configs in r.js ?
>>> For my optimizer it has become quite involved on how to tackle the issue of
>>> the multiple modules defining themselves with the same id within the same
>>> delivered javascript stream.
>> I do support them in r.js, at least to the extent that the above tests
>> pass. If you have a tricky test case though, I am interested to see
>> it.
>> James
> Thanks for the clarification.
> I think it would be best to modify the text in the spec to avoid
> confusion. Perhaps changing the wording to :
> "Object. Specifies for a given module ID prefix, what module
> ID/prefix to use in place of another module ID/prefix"
> What do you think ?
> I took a look at the tests you have in requirejs and converted a
> few of them over to run in amdjs-tests. I took "mapConfig",
> "mapConfigStar" and "mapConfigStarAdapter". The others seemed to
> be more requirejs specific.
> The "mapConfigStar" test has highlighted another gotcha (at least
> for me with the approach I have taken).
> There is a map configuration of
> '*': {
> 'c': 'another/c'
> },
> The 'another/c' module has a peer reference to a module called
> './minor' so the full mapped id for it would be 'another/minor'.
> At the moment the approach I have taken is not modify the ids that
> are written into the modules. That is they are in unmapped form.
> This results in multiple define calls with the same id. To handle
> this I add the matched mapping as an additonal parameter to the
> define call and that is used to better qualify the id of the
> module internally. With this approach I don't have to mess with
> the dependent list to modify the mapped id there too. This works
> for mapped ids and prefixes but the peer module has caused me
> problems. Looking at your built version of the "mapConfigStar"
> test I see that your code writes in the mapped ids. I'm curious to
> know if you also modify the modules dependency lists too for these
> mapped ids.
> On Sat, Sep 8, 2012 at 10:52 AM, Richard Backhouse
> <richardabackho...@gmail.com> wrote:
>> James, if it helps I can fork the amdjs-tests repo and create a push request
>> with these 3 tests I've added.
> That would be awesome!
> I also updated the config page to what you suggested, but instead of
> "ID/prefix" I just said "ID prefix". So:
> "Object. Specifies for a given module ID prefix, what module ID prefix
> to use in place of another module ID prefix"
