cujojs / curl

curl.js is small, fast, extensible module loader that handles AMD, CommonJS Modules/1.1, CSS, HTML/text, and legacy scripts.
https://github.com/cujojs/curl/wiki
Other
1.89k stars 216 forks source link

please clarify syntax for plugin and source path in docs #169

Closed jcollum closed 11 years ago

jcollum commented 11 years ago

From the docs:


curl = {
        paths: {
            cssx: 'cssx/src/cssx/',
            stuff: 'my/stuff/'
        }
    };

... later 

'cssx/css!stuff/base', // a css file

for a link to the file: /js/my/stuff/base.css

OK that's really confusing. Why is cssx in that path spec? why is css! after the path prefix? From reading that combination of basepath and 'curl' path, it looks like the file should be at /cssx/src/cssx/my/stuff/base.css.

My understanding is that the path spec goes like this:

[basepath(s), optional] [/, if a basepath present] [plugin, if needed] [path] [file name] [file extension (optional)]

It'd be nice if the docs spelled this out more clearly. I've been having to brute force it (by trying to load a js file from several paths and seeing what works).

Honestly having the basepath before the plugin is confusing as well. I'd prefer the plugin to use to be the first term. Note that I haven't provided a pull request to do this, so you can take that part with a grain of salt :)

unscriptable commented 11 years ago

Hey @jcollum,

The plugin's module id (and/or url) do not affect the resolution of the resource's module-like id (or url).

The AMD spec is a bit confusing, at first, especially when it concerns plugins. The format is

<plugin id> "!" <anything>

Most plugins, however, treat as a module id which allows the plugin to rely on the module id resolution and path resolution rules of the loader. If the plugin relies on the loader, the format is essentially

<plugin id> "!" <resource module-like id>

Since a plugin id could be part of a larger package, it could have path bits in it. In the example you pasted, the plugin's full id is "cssx/css", where "cssx" is the path bit (typically, that would be the name of it's package) and "css" is the local module id within the package.

The resource id resolution works the same way.

Url resolution happens after module ids are resolved. The "paths" config is used to map module ids to urls. The relative url for the cssx/css plugin module is cssx/src/cssx/css, and the css resource's relative url is my/stuff/base.css. These are then joined onto the baseUrl to create the final url.

cssx/css!stuff/base resolves to the same place as cssx/src/cssx/css!my/stuff/base.css

You could just use the latter form in your code, but using url paths instead of module ids creates code that is harder to refactor and harder to deploy since you can't move modules around as easily.

Have you read this? Maybe that can help a bit, too.

Regards,

-- John

unscriptable commented 11 years ago

closing this, but feel free to keep posting here or use #cujojs on freenode. You can also just post questions on the google group: https://groups.google.com/d/forum/cujojs