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
> * 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
Having config object at the top level makes more sense to me.
Richard
String: The module prefix uses "package rules". The prefix can only be the first segment of an absolute module ID.
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
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
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
Simple applications don't need to worry about any of this.
--Rawld
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
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"?