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

A question about how the id cache works when using plugins #222

Closed manast closed 10 years ago

manast commented 10 years ago

Hello,

I am having a problem with curl id cache, that may be for me lacking to understand some basic piece on how paths works.

Lets say i have a resource at some relative path:

templates/a.tmpl

I can just read the resource with:

cur(['text!templates/a.tmpl'], function(tmpl){
...
}

When debugging curl I can see that this resource has been cached in this entry:

curl/plugin/text!templates/a.tmpl

Now if I am running a build step, I may have defined my template inlined somewhere like this:

define('text!templates/a.tmpl', function() { return "foobar" });

But this will create a cache entry with just this key:

text!templates/a.tmpl

Which looks ok to me, but of course it is not the same key as the one that curl is going to look after when somebody depends on that resource, thus triggering a GET to try to load it instead of using the cached one...

Is there any way to instruct curl not to prepend the relative path of the plugin to the cached key of the resource?

unscriptable commented 10 years ago

Hey @manast,

Sorry this got lost in my inbox.

curl.js and cram.js operate on the following principle: module ids in the cache at run time (curl) and in bundles (cram) should be fully transformed. This means that ids are normalized (leading dots reduced) and any id transforms are performed.

The pluginPath config variable is used to tell curl how to transform a simple plugin id to a full plugin id. You can set is to a blank string to tell cram or curl not to transform the id.

Feel free to reopen this issue if I haven't answered your question. :)

-- John