We (the cujojs team) are getting way too many inquiries (aka "complaints"
:) ) about a similar situation. When using plugins, there's no standard
way to propagate loading errors back to the AMD loader. (Side note:
relying on time-outs in the loader to detect loading errors in plugins is
not a solution, imho. It's impossible to determine the correct value.)
curl.js adds a `require.reject(ex)` callback to the `require` injected into
the plugin's load method. curl.js listens to that function so it can
handle the error and pass it on to any handlers the dev has added. We use
this in all our plugins to signal that the plugin-based resource (legacy
The name "reject" is certainly open for debate -- as is the possibility of
changing the load method's signature instead. Regardless, something like
this would seem to go well with the `require(deps, callback, errback)`
On Mon, Apr 23, 2012 at 4:58 PM, John Hann <j...
> I'm very happy with `require(deps, callback, errback)`. It seems like
> it's really safe and easy to implement. Unless somebody has a major
> objection, I'm going to implement this. :)
> On Tue, Apr 10, 2012 at 12:27 AM, James Burke <jrbu...@gmail.com> wrote:
>> On Sun, Apr 8, 2012 at 12:18 PM, Adam Peller <pel...@gmail.com> wrote:
>> > I'm intrigued by the idea of using Promises directly on require.
>> > are typically going to use something like a Promise anyway, so why not
>> > encourage the same pattern? Chaining Promises could make the call much
>> > cleaner and avoid the need (and likely neglected step) to manually wire
>> > an errback function. Is this still a candidate? Is the dependency
>> > considered too heavy? Would John's third example represent a
>> I still think they add more complication to the API than what is
>> needed, and prescribe too much of an implementation. I like using
>> promises in my own app code though.