Throws error: Multiple anonymous defines when using js! to load AMD modules and then calling the text! plugin

[manast]

This could be a duplicate of #243, I have found the reason for this error as it happened in my codebase.

Just to quickly introduce my use case. I have a quite complex application divided in many AMD modules where I load dynamically styles and templates on demand.
The problem happened when I used the text plugin. In some situations, when the "define" in the text plugin was called, I got a Multiple anonymous defines encountered' error.

The error is triggered because I happened to load one AMD module with the
js! plugin. This was a third party module that did not support AMD before,
but that has beend wrapped to be AMD compatible recently. What happens is that
the module is loaded with the js! plugin, and when the module is loaded it executes the define inside that module, which becomes superfluous since we loaded the module using js! in the first place. Due to this, the argsNet variable gets a non undefined value, and since argsNet only gets cleared in the success call of loadScript, but no script is loaded now it will not be cleared this time.

After this situation If I make an explicit call to "curl" to load a text asset,
(curl(['text!example.txt'], ...)) it will first try to load the text! plugin, which is also anonymous, and as soon as it calls the define method inside the text plugin it will check that argsNet is not undefined and schedule an error that will be reported when loadScript's success callback for the text plugin is called.

So, I could fix this in my codebase by simply not using the js! plugin for this AMD module. I must say it has been quite painful to find the solution, specially because it does not happen consistently all the time, there may be some asynchronous undeterministic behaviour that sometimes cleans the argsNet variable and avoids the exception.

[unscriptable]

Hey @manast. This problem also happens when newbs don't bother to check if a library is AMD compatible or not. The only way to deterministically know when this problem has occurred is inside the js! plugin or the legacy loader, not inside curl.js. I haven't checked the code yet, but I don't even know if it is possible at all, atm.

If it is possible to determine, we may have to expose a private API to signal that argsNet is no longer valid, I guess???

-- John

┏( ＾◡＾)┛ ┗(＾◡＾ )┓ I rock RaveJS! ┏( ＾◡＾)┛ ┗(＾◡＾ )┓

On Apr 23, 2014, at 9:47 AM, Manuel Astudillo notifications@github.com wrote:

This could be a duplicate of #243, I have found the reason for this error as it happened in my codebase.

Just to quickly introduce my use case. I have a quite complex application divided in many AMD modules where I load dynamically styles and templates on demand.
The problem happened when I used the text plugin. In some situations, when the "define" in the text plugin was called, I got a Multiple anonymous defines encountered' error.

The error is triggered because I happened to load one AMD module with the
js! plugin. This was a third party module that did not support AMD before,
but that has beend wrapped to be AMD compatible recently. What happens is that
the module is loaded with the js! plugin, and when the module is loaded it executes the define inside that module, which becomes superfluous since we loaded the module using js! in the first place. Due to this, the argsNet variable gets a non undefined value, and since argsNet only gets cleared in the success call of loadScript, but no script is loaded now it will not be cleared this time.

After this situation If I make an explicit call to "curl" to load a text asset,
(curl(['text!example.txt'], ...)) it will first try to load the text! plugin, which is also anonymous, and as soon as it calls the define method inside the text plugin it will check that argsNet is not undefined and schedule an error that will be reported when loadScript's success callback for the text plugin is called.

So, I could fix this in my codebase by simply not using the js! plugin for this AMD module. I must say it has been quite painful to find the solution, specially because it does not happen consistently all the time, there may be some asynchronous undeterministic behaviour that sometimes cleans the argsNet variable and avoids the exception.

—
Reply to this email directly or view it on GitHub.

[manast]

alternatively changing the mechanism of determining multiple defines. Somehow I have the intuition that there must be a simple more robust way to do it than using argsNet.