Same issue with relative paths (Issue 21).

This is proving to make development of new modules challenging, as the framework is "live", but modules in development still need to point to this framework. I don't seem to have a good way to override dependencies without pushing them to the live environment too.

More importantly, here's some code to bring this situation to light:

<script>

    curl: { paths: {
        "css!": "//css.mycdn/", 
        "shared/indev-module": "//localhost/indev-module/indev-module", // this works OK -- though would be even better if relative paths also worked (Issue 21)
        "css!shared/indev-module/indev-module.css": "css!//localhost/indev-module/indev-module.css" // absolute nor relative works. this property effectively is being ignored
    }
    };

</script>
<script src="http://mycdn/shared/curl/v0.5.3/curl.js"></script>
<script>
    require(["shared/indev-module"]);
</script>

As for the contents of "indev-module.js":

define("shared/indev-module", ["css!shared/indev-module/indev-module.css"], function () {

 // define my module

});

1. I'd expect my path setting to replace "css!shared/indev-module/indev-module.css" with "css!//localhost/indev-module/indev-module.css", which it does not. It's like the path setting is being ignored entirely. I suspect the part about the path being ignored is the result of having a default "css!" path.
2. As a work-around (keeping in mind this is for in-development modules), I provided the absolute path of the dependency. So instead of depending on "css!shared/indev-module/indev-module.css" in the "define" call, I provided "css!//localhost/indev-module/indev-module.css". To my suprise, not even this worked -- instead, it tried to add the path to the baseUrl. Absolute paths should always take priority and ignore the baseUrl. I'd expect relative ("./" or "../") pathing to work here too (Issue 21), but that isn't as critical of an issue.

As to the 1st issue, this is likely due to using "paths" even for plugins, instead of allowing plugin-based baseUrl's to reside external to "paths" -- Making this change would allow both absolute and relative paths to take priority over plugin baseUrl's. This would be consistent with how plugins now take priority over the baseUrl.

The 2nd issue, from best I can tell, is simply a bug.

Hi,

I just tried curl.js.
I change the apiName to 'require' in order to apply it on my requireJs project.

Unfortunately I have a problem with jQuery 1.7.1, which works fine with require.js

Actually I have this error :

Uncaught Error: define() not found or duplicates found: jquery-1.7.1.min.js

You can reproduce it easily with this gist

https://gist.github.com/1394883

Am I doing something wrong ?

Cheers
Romain

@bryanforbes noted that the config object passed to plugin load method is empty. Ensure that the current test ( in 0.6 / dev branch) passes for Bryan's case, too.

Line 189 of README.md is missing a comma after cssx: 'cssx/src/cssx'.

Requiring "curl(['module1'])" instead of "curl('module1')" is inconsistent with the specifications for AMD, see https://github.com/amdjs/amdjs-api/wiki/AMD

This actually caused me to have difficulty in initially utilizing the library as I was using single dependencies, not realizing that the array was currently required.

I've been using requirejs for a while now and curl looks identical in almost every way. Am I missing something? What is the advantage of curl over requirejs?

Thanks!

Lance

This happens when using one of the dist/ versions of curl and the new preload feature at the same time. curl starts processing the modules specified in the preload array before the browser finishes executing the curl.js file. Therefore, it starts downloading the preload modules before the define() calls for those same modules are executed in the curl.js file.

This only happens when using curl = { /* config with preloads */ };, not when using curl({ /* config with preloads */ }, deps, cb);.

I am running the following test to check if the underscore shim solves the problems it should be solving:

  require(['curl/shim/underscore'], function() {
      console.log('loaded!');
      require(['underscore'], function(_) {
        console.log(_.template);
      });
    });

The reason why I'm checking for template is because it's the last thing to be defined on underscore (this is 1.2.2 btw).

After taking a look at the shim code and poking it for a while, it looks like when it tries to get core['_define'], it's still not defined, so it might get overwritten later. I've tried a few setTimeouts but nothing seemed to solve the issue.

No code changes on my side, just getting the latest (unpackaged, unminified) curl.js is not firing my modules callback.

curl(["js!jquery.js"], function() { }); // loads, and performs callback OK
curl(["module1"], function() { }); // loads, but does NOT callback

// module1.js
define("module1", ["js!jquery.js", "link!module1.css"], function() { }); // all resources load, but does NOT callback

Being everything is loading, just not calling back, hard to say if the issue is in curl or the "js!" plugin. I removed the "link!" dependency temporarily to verify it was not the culprit.

Some new features were added in 0.5.2. Close this ticket when they're documented in the README.md.

<script>
  curl = {
    baseUrl: "//cdn1/"
  };
</script>
<script src="//cdn2/curl.js"></script>
<script>
  curl("module1_from_cdn"); // works as expected
  curl("./module2_from_same_app"); // tries to hit baseUrl instead of same domain
  curl("js!../js_from_same_app.js"); // tries to hit baseUrl instead of same domain
</script>

It's my understanding that only forward-relative paths should be hitting any pathing configurations, otherwise you have no way to load from same-domain without using an absolute path (i.e. "js!/abs_path/file.js"). We should be able to prefix paths with "./" or "../" to avoid pathing. I suppose it's possible for some situations that desire backward-relative paths from the baseUrl (or other "paths"), but that could be a pain in some situations, especially local test pages.

I misunderstood the capabilities of the "path" configuration, as I thought it could be used to specify different end points based on the plugin (i.e. "js" goes to "js.cdn.com", "css" goes to "css.cdn.com", etc). Not being able to use different endpoints for all file types is a big problem. Obviously specifying the full domain/path for every resource is not a realistic option. Without this some apps would be slower than they are without the loader, negating most of the purpose of using it to begin with.

Am I missing something, or is it currently not possible to do this?

My app is layed out like this:

• /index.html
• /js
  • /lib
    • /curl-0.5.2.js
    • /curl-plugins
      • /domReady
      • /js.js
    • /jquery-1.6.2.js
    • /jquery.tablesorter-2.0.5

index.html:

<!doctype html>
<html lang="en">
<head>

    <script>
        // Configure curl.js
        curl = {
            pluginPath: "lib/curl-plugins",
            paths: {
                lib: 'js/lib'
            },
            apiName: 'require'
        };
    </script>
    <script src="js/lib/curl-0.5.2.js"></script>
    <script>
        require(['js!lib/jquery-1.6.2.js!order'])
            .next(['js!lib/jquery.tablesorter-2.0.5!order'])
            .then(function() {
                require(['domReady!'], function() {
                    $('body').text('loaded');
                });
            });
    </script>

</head>
<body>

</body>
</html>

Now the js! plugin loads finde from 'js/lib/curl-plugins'. The call to the domReady! plugin fails however, curl tries to load it from 'curl/domReady.js' (which seems to be the default plugin location) instead of respecting my pluginPath setting.

The error

The module at util/foo.

define('foo', { foo: 'bar' })

The loading:

require(['util/foo'], function (f) { console.log(f) });

Gives this error: Error: define() not found or duplicates found: /path/util/foo.js

RequireJS loads it just fine.

Why would we do this?!

We're migrating our codebase to AMD, but its far too large to do all at once, so we're dropping in curl.js or require.js and using it for new development, and will go back and convert old code over time.

The end goal is to use the require.js optimizer and then curl.js in the browser, but not until everything is converted to AMD. So, for the time being, we are still using our old build process to concat all our JS together with Jammit and are naming our modules by hand.

However, for our specs / development of new stuff we'll be loading things asynchronously so we need it to be able to load named modules as if they were unnamed.

tl;dr

Review the following code:

<!doctype html>
<html lang="en">
<head>
    <script src="js/curl-0.5.2.js"></script>
    <script>
        curl(['js!js/jquery-1.6.2.js'], function() {
                $('body').text('loaded');
            });
    </script>
</head>
<body>

</body>
</html>

Curl tries to load jQuery from / for some reason. Adding !order to the jQuery load fixes this. But according to the doc of the js! plugin !order is optional.

Not sure if I'm doing something wrong, but I cannot get curl.js (I build the plugins into it using an already established make process) under the dev055 branch to work at all. When requesting:

  curl("js!http://domain.tld/test.js");

All this does is request "undefined". Was this branch not ready for testing?

First of all, I want to clarify, "package" refers to a single javascript file which contains a compilation of two or more modules, for optimization purposes.

So lets just dig into an example, and it should be clear what the issue is in this situation:

<script src="curl.js"></script>
<script> // preloads!
curl("my-super-package"); // contains module1, 2, and 3
</script>

<!-- 
in a completely separate (and dynamic) part of my application, I'm going to dynamically inject content and load the individual modules required by the content
-->


<script>
curl("module2", function() { // use module2
});
</script>


<script>
curl("module4", function() { // use module4
});
</script>

OK. So the problem should already be clear, but lets talk this out. We've got a race condition, with module 2 (as it should not be downloading "module2" since it is already inside of the package). So why would we have code like this? You've got a huge application, where not all parts talk with one another, but you've got some form of "master" (potentially a few) where your common work takes place (such as including curl, and pre-loading common files such as this "package"). Ideally, we want to allow these types of disconnects between the master and the child pages, as it can be very difficult to keep everything in sync otherwise.

Of course, I could simply remove the inclusion of the "package", and all is well again. In a perfect world, developers can throw in their "curl" calls left and right, for each and every requirement they have, without concern over what has already been included, or what packages may have been included. And as "common" files change, we swap out with different packages in the header. The potential here is some substantial optimization's in the "master" with no impact on the remainder of the application -- if it worked, that is.

I have some ideas on how this could be addressed, but wanted to first throw the problem out there. I'm not sure if it is a limitation of AMD, or a misuse of it, or otherwise.

Hi

I optimized my web app with r.js, and then I use curl.js to load it but jQuery is downloaded even when it is already present in the optimized file.

You can see this with those pictures:
http://twitpic.com/7kpynd
http://twitpic.com/7kpz18

You can reproduce it with this gist
https://gist.github.com/1397906

I'm porting a non-AMD app from script.js to curl.js, converting to AMD modules as I go along.

I figured I could start off by wrapping some non-AMD libs in define(), starting with jQueryUI, then ran into what I believe is a curl.js bug, but could also be idiocy on my part.

I'll summarise the scenario as follows:

<script type="text/javascript" src="curl.js"></script>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
<script language="javascript">
   define("ui", ["jquery!order", "js!jquery-ui.js!order"], function(){});

   ... some other code which uses the new "ui" module...
</script>

The result is:

Uncaught TypeError: Object function (a,b){return new e.fn.init(a,b,h)} has no method 'load'    curl.js:564

Now, removing the "!order" tag makes the problem go away, but it doesn't seem like the Right Thing To Do. I guess that in the above code, jquery isn't getting loaded via require, so perhaps that confuses the order plugin.

-Steve

Could you start a plugin for isolation of modules for tests like https://github.com/JamesMaroney/requirejs-isolate/
I would like to do it myseft but it impact the dependency system that you understand much better than me :).

Using the 0.5 release, with "dist/curl-kitchen-sink" or "dist/curl-with-js-and-domReady", the following code will result in an unexpected request for domReady.js file... My understanding is that the "domReady" plugin is part of these distros, so is this a bug or am I missing something?

<!DOCTYPE html>
<html>
<head>
    <title>Index</title>
    <script src="scripts/curl.js"" type="text/javascript"></script>
</head>
<body>

<script>
    curl(["js!scripts/test.js"])
    .then(function () {
        console.log('test1 done');
    });
</script>


</body>
</html>

I noticed there is somewhere between 500B and 1KB of console-logging-related functionality in the minified loader (kitchen sink distro). Just noticed it by chance, so thought I'd mention it since you put so much effort into shrinking the loader. I wouldn't want to enable logging in a release loader anyway.

I may not understand the intended meaning of the .next statement. However, I am trying to do the following: stage loading of files in tranches before the main code executes.

File testNext.html:

<head>
    <title></title>
    <script type="text/javascript" id="curlConfig">
        curl = {
            paths: {
                curl: '/sharedJs/unscriptable-curl-5ac0fcd/src/curl/',
            },
            jsPrefetch: true
        };
    </script>
    <script src="/sharedJs/unscriptable-curl-5ac0fcd/src/curl.js" type="text/javascript"> </script>
    <script type="text/javascript">
        var steps = 0;
        curl([ 'js!sharedJs/jquery.js' ])
        .next([ 'js!stepOne.js' ], function(){ steps = steps+1; })
        .next([ 'js!stepTwo.js' ], function(){ steps = steps+2; })
        .then( function()
                {
                    $(document).ready( function(){
                                                    alert( steps );
                                                    testOne();
                                                    testTwo();
                                                 });
                }
                ,function(){alert("something wrong")});

    </script>
</head>
<body>
</body>

stepOne.js:
var testOne;

$(document).ready(function()
{
testOne = function() { $( 'body' ).append("<p>Test One!</p>") }
});

stepTwo.js:
var testTwo;

$(document).ready(function()
{
testTwo = function() { $( 'body' ).append("<p>Test Two!</p>") }
});

On loading the page, an alert box appears saying "2". The console shows "testTwo is not defined". Inspecting the page shows that a script element has been made for stepOne.js, but not for stepTwo.js. So it looks as if the requirement for the first .next statement has been fulfilled, but its callback is NOT executed; and the requirement for the second .next statement has not been fulfilled, but its callback has been executed.
Thanks,
Joop

Create the i18n plugin. It should initially behave like dojo's and RequireJS's i18n plugin. (Later, we'll likely add a feature to prefetch / inject strings that may be stored and/or retrieved by an alternative mechanism. For instance, a project could use this feature to preload a customized bundle for a particular client or OEM.)

Hello John,

I’ve found a bug in css plugin: an attempt to load an empty CSS-file as a dependency leads to endless call of ssWatcher function. Moreover, in Chrome such dependency can’t be resolved or rejected. You can use the following code as a test case:

curl(["css!empty.css"], function() {
    alert("loaded");
});

Best regards.

Hello,

First of all I would like to thank you for the great loader. It is very useful.
I found a bug in curl.js that leads to problems when a JS file is used as a dependency with and without !order option. Namely, if one module depends on "someFile.js" and another module depends on "someFile.js!order", then this situation causes double loading of "someFile.js". As a result some strange and difficult to find bugs can occur in an application. The problem has its roots in the following part of fetchDep function (lines 541 and 542 in curl.js):

name = prefix + '!' + resName;
normalizedDef = cache[name];

As you can see there is no test for options in "resName".

Best regards.

The following will not work (note: 1 script tag):

<script>
var $namespace = {}; // I don't expect curl to auto-create the parent objects
curl = { apiName: "$namespace.require" };
/* include curl */
</script>

$namespace.require should work, but does not. Instead, I need to require an additional script block following the include, something like (note: 2 script tags):

<script>
 curl = {}; // my config stuff
/* include curl */
</script>
<script>
  $namespace.require = curl;
</script>

Not a huge deal, but for a snippet of code that will be copy/pasted a lot, it'd be nice to remove excess clutter (providing a single script block), since the feature "apiName" already exists for this purpose.

The test for the !noexec option for the js! plugin seems broken.

Extension detection is important as it determines if the '.js' extension should be appended to the module or not. But if the file happens to utilize a querystring (i.e. "dynamic_scripts/script1.js?do=this"), it will instead try to request "dynamic_scripts/script1.js?do=this.js". This is pretty minor, as I can get around this by doing something like ""dynamic_scripts/script1.js?do=this&test" (resulting in ""dynamic_scripts/script1.js?do=this&test.js"), but still a bug so wanted to make you aware.

I have the following structure:

eventd/
|_ curl/
|   |_ curl loader source
|_ test/
    |_ foo.js
    |_ plugin.js
    |_ test.js
    |_ test.html

The files look like the following:

foo.js

define([], function(){
    return {
        foo: "bar"
    };
});

plugin.js

define([], function(){
    return {
        load: function(id, require, load){
            require([id], load);
        }
    };
});

test.js

define(["./plugin!./foo"], function(foo){
    console.log(foo);

    return foo;
});

test.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Test Page</title>

    <script>
        var curl = { baseUrl: '..' };
    </script>
    <script src="../curl/src/curl.js"></script>
    <script>
        curl(['test/test'], function(test){
            console.log(test);
        });
    </script>
</head>
<body>
</body>
</html>

When I load test.html, I get the following error:

GET http://projects.local/eventd/plugin.js 404 (Not Found)
curl.js:705 Uncaught Error: Syntax error or http error: .././plugin.js

It seems that curl doesn't accept a relative path to a plugin module, which makes it very hard to write a library. There seems to be another problem as well: if I change the reference from ./foo! to test/foo, I get the following error:

GET http://projects.local/foo.js 404 (Not Found)
curl.js:705 Uncaught Error: Syntax error or http error: /foo.js

It looks like it's looking for the foo module at the root of the server. In fact, the id passed to load is /foo. Is this right?

I'm passing a config that looks like this

...
'paths': {
...
'eaf.util': 'my/eaf/core',
'eaf.core':'my/eaf/core'
...
}

core.js defines both 'eaf.util' and 'eaf.core' by name.

I also have a module that is like this:

define('domain.base', [..., 'eaf.util', 'eaf.core'...], function (...

Trying to load this last module with curl results in "Promise already completed." To get around this, I replaced the throw with a return. Not sure of all the dangers, but I'm just trying to get curl working and am purty frustrated at this point, I have to say. fyi, I'm trying to migrate from http://jsclass.jcoglan.com/ loader pattern, which is why it seems paths are the shortest path to success.

Hello,

I would like to use this syntax with curl.js...

var foo = require('foo');

I've seen this in the requirejs documentation, however it doesn't appear to work with curl.js. I get the following error:

"Uncaught Error: Module is not already resolved: foo"

Is this even supported in curl.js?

Many thanks, using curl.js extensively in our project. We really like it.
/t

Underscore.js is, according to the documentation, supposed to work in requirejs. When I try to use it together with curl, I get the following error and callstack:

Uncaught Error: Promise already completed.
b curl.js:4
b curl.js:4
b curl.js:7
K curl.js:9
R curl.js:7
b curl.js:11
(anonymous function)underscore.js:11
(anonymous function)

But the strange thing is that despite the error, underscore is available. I used the same approach as for loading jquery, i.e. added underscore to the paths option:

      curl = {
        baseUrl:'/js',
        paths:{
          shaders:'../shaders',
          underscore:'lib/underscore'
        },
        apiName:'require'
      };

Then in the modules that depend on underscore:

define(['underscore'], function(_){ ... });

Any ideas why this error is happening?

This is a non-issue for me as I am not using this feature, but wanted to make you aware since I caught it.

<script>
curl = {
   baseUrl: "//cdn1.mydomain.com/root/",  // WONT WORK
   pluginPath: "//cdn2.mydomain.com/root/curl/plugin",  // WONT WORK
   paths: {
      js: "//cdn3.mydomain.com/root/curl/plugin/js" // WONT WORK
   }
}
</script>
<script src="cdn1.mydomain.com/root/curl/curl.js"></script>

The above code will not work. I believe what it is doing is detecting a prefix of a single-forward slash "/" to detect for an absolute path, and ignoring the fact that double-forward means something entirely different.

Not sure how I've gotten away without discovering this bug until now, but it has proven troublesome with existing prod code. Here's the issue in a nutshell:

curl = {
  baseUrl: "//cdn1/", // default path
  paths: {
    "css!": "//cdn2/" // default path for css includes
  }
};

The above script (a variation thereof anyway) is built into our master curl include. Now performing the following in the App:

require("css!/css/test.css"); // instead of hitting the absolute path (instead of the path override since it is absolute), it is hitting //cdn2//css/test.css

It is entirely possible the issue I noted above is just a variation of the same problems in some of the other 0.5.3 issues reported, and may not even be specific to the "css!" plugin (though I was unable to repro with the "js!" plugin, but wanted to make aware just in case.

The only temporary workaround I could come up with for now (that is working so far) is:

curl = {
  baseUrl: "//cdn1/", // default path
  paths: {
    "css!": "//cdn2/" // default path for css includes
    , "css!/": "/" // if prefixed with "/" use that instead
    , "css!//": "//"
    , "css!http:": "http:"
    , "css!https:": "https:"
  }
};

Messy, but it gets the job done.

Hi,

Something I found useful in requireJs and I don't find in curl.js is the YepNope syntax.

For exemple, if I depend on polyfill before loading my app, I can do something like this with RequireJs :

require([
  window.fn1 ? '' : 'js!fn1.js',
  JSON.parse ? '' : 'js!fn2.js'
], function(){
  console.log('Loaded');
})

The empty string and the null value does not work well with curl.js

We start to have a lot of AMD implementation, and that's great. BTW, each implementation has it's own way to handle loading plugins, and it's not a good idea.

Making loader plugin a standard provided by Curl will improve the number of total plugin available for it and in general for AMD, helping to its diffusion as a standard for loading modules (at least on the browser side).

If the spec isn't satisfying, it could be a good idea to contribute to it also ;)

If a path mapping looks like the following:

path: {
    curl: 'curl/src/curl'
}

then curl doubles the path mapping as follows:

"curl/src/curl/src/curl"

It would be very useful for the loader to automatically rewrite all http uri's to be https when executing under an https application. Optionally, you could add a "AutoHttps" setting to the config (default: true) if you prefer, but for any real-world use you always use https requests for https applications. Naturally, it if not running under an https app, there is no difference, requests continue through http.

This simplifies complex applications from having to remember to support both cases for every dependency. There are some cases where the caller may want to control both their http and https url's, which will also work, as you do never rewrite already https uri's even on an http application.

Hello,

I was thinking that something that would be really cool and add a lot of new possibilities would be to implement some kind of middleware engine into curl.

A middleware could be similar to what we are used to in frameworks such as connect:

function cacheMiddleware(deps, callback, next){
  var result = {}
  var newDeps = []
  for(var i=0; deps.length;i++){
    if(deps[i] in resourceCache){
      newDeps.push(deps[i])
      result[deps[i]] = resourceCache[deps[i]]
    }
  }
  next(newDeps)
  callback(result)
}

The middleware takes as input an array of dependencies urls, will do something with them (for example check them in a cache, transforms them in any way etc), when finished it will call next which will in fact call the next middleware in the chain. Since everything is asynchronous we should not return anything, instead call a callback with the result of the middleware (which should be the resolved urls into strings with data). The current fetcher and caching code could be implemented as middlewares as well.

A solution like this could for example be used for amazing things such as:

• Use localStorage/sessionStorage for caching modules.
• Using other transport protocols for fetching modules from a server, for example socket.io
• Having a server component that co-works with the loader, so that for example you can request several modules
  at the same time to reduce the amount of roadtrips.

What do you think?

Hello,

This isn't really an issue with curl itself, more a problem with working out how to correctly compile it using closure.

I'm attempting to build a file with curl and the domReady and script plugins. Are you able to tell me the correct cmd line?

This has been my best effort so far...

java -jar compiler/compiler.jar --js=curl.js --js=curl/domReady.js --js=curl/plugin/domReady.js --js=curl/plugin/js.js --js_output_file=curl.min.js

Thanks,
Tom.

This is more of a stupid question than a bug, but it's something I haven't been able to figure out.

According to my understanding of the documentation and READMEs, if I bring in a build of curl that includes the link! plugin--such as the one labeled "kitchen sink"--I shouldn't ever need to tell curl where to find said link! plugin. Nevertheless, as soon as I try to get curl to load something which asks for the link! plugin, it fires off an HTTP request for link.js in the default pluginPath which obviously 404s.

I'm clearly doing something very wrong, but am at a loss as to what that might be.

Any plugins that reside at the top level (i.e. at baseUrl) are basically "naked" as defined in the wiki (https://github.com/unscriptable/curl/wiki/Plugins). Therefore, the loader prepends the pluginPath onto them. This causes the loader to look in the curl/plugin folder rather than at the top level.

There is a work-around for this issue: include an entry in the paths config like this:

paths: {
    myplugin: './myplugin'
}

The existence of the slash is enough for the loader to no longer consider the plugin id to be "naked".

During evaluation I determined the "domReady!" callback seems to fire after all initial calls of "curl" have loaded. A clear case of this is hitting a dynamic endpoint mimicking that of a js file, but with long sleeps to expose the vulnerability.

The easiest comparison is with jQuery.ready, which fires when the dom is actually available, rather than after all resources have finished loading. It does work as expected in IE9 (have not tested older).

curl's algorithm for cascading module dependencies is aggressive. It doesn't wait for the "next turn" before cascading a module's exports to dependent modules and can therefore, call the cascading define() calls before the exports are fully defined.

While we (@cujojs) don't consider this to be a bug in curl.js (it decreases load time significantly), we believe we should have a better way to accommodate naively-coded AMD modules that export too early.

This could be a config property: waitForNextTurn: true

or the converse: cascadeAsap: true

Using:

curl(['module-v1_0']);

Will fetch 'module-v1_0.js' automatically. But using:

curl(['module-v1.0']);
// or
curl(['module-v1.0.html']); // cross-domain html file include

Will fetch 'module-v1.0', using '.0' as the extension (or 'module-v1.0.html' with '.html' as the extension).

While this may appear to be a harmless distinction, it provides inconsistency, which may be unnecessarily confusing in implementation on a large scale. Isn't it true that if you do not use a plugin ('plugin!filename') that it is in fact a module? I'd say requiring ".js" on the end of every module is a reasonable expectation, as it already assumes this for no extension.

If for whatever reason, someone wanted to include modules with a different extension, this could possibly be wrapped in a small plugin such as "mod!mymodule.mod".

Thoughts?

define(['exports'], function(exports){ ... }) causes curl.js to attempt to load exports.js, rather than treat it as a reference to the free exports variable. Omitting the initial array causes curl to load require.js, exports.js, and module.js, resulting in an error. I've created a simplified test case to demonstrate the problem.

The current "css" plugin is pretty hefty, and still does not fully work for all browsers across domains. Have you considered a simpler plugin, that simply does not support callback AFTER load (same behavior as current "css!myfile!nowait") since it takes very little code to achieve a link insert? Trying to avoid having to define css dependencies elsewhere, outside of curl, as it's clunky, especially with dynamically injected modules.

I've created a gist to explain what I'm doing: https://gist.github.com/1521659. This is the way the has plugin works in Dojo and the Dojo loader resolves this correctly. For some reason, curl is resolving the module returned by the plugin as an array containing the module.

The following errors were seen when using a built/dist version of curl:

1. using the !exports=foo.bar option of the js! plugin sometimes fails.
2. exports objects in circular dependencies sometime resolve too early