Double loading of JS-file with and without !order option

[gamtiq]

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.

[gamtiq]

I have created a small application that demonstrates the problem. You can see double loading in "Net" tab in Firebug or in console in Firebug/Chrome. The application can be downloaded using the following URL:
http://www.mediafire.com/file/mth9d9owmb32d35/curl-js-file-double-loading-bug.zip

[unscriptable]

Thanks for discovering this, gamtiq!

The solution for this is to add the normalize() method to the js! plugin.
This method allows the js! plugin to determine the uniqueness of a
resource id.

Do you need a work-around for now or can you continue to work for a few
days without this fixed?

Regards,

-- John

On Mon, Nov 7, 2011 at 3:06 AM, gamtiq <
reply@reply.github.com>wrote:

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.

---

Reply to this email directly or view it on GitHub:
https://github.com/unscriptable/curl/issues/30

[gamtiq]

No, I don’t need immediate fix for this issue because I have already found and implemented a work-around in my application.