See here for details:

http://tagneto.blogspot.com/2012/04/draft-plan-for-requirejs-20.html

Feel free to provide feedback in the link on the wiki page, or on this
list thread.

James

requirejs-rails users can give this a whirl by dropping this into your Gemfile:

gem 'requirejs-rails', :git => "git://github.com/jwhitley/requirejs-rails.git", :branch => "dev2.0"

I'll be updating this periodically.  The commit log on the branch includes the upstream commit ids for require.js and r.js.  Feel free to give a shout out if it needs updating.

-- John

Great work, it looks really good so far.

I really like the legacy option. I think it will allow for an easier
transition into AMD.

I think there should be some built in support for retrying modules that
failed to load. The errback idea is nice, but I think its a little to
verbose and it feels a little too RequireJS. What if we changed the path
config like so:

requirejs.config({
    paths: {
        jquery: ['http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min', 'local/jquery']
    }});

By specifying an array of locations, we can have RequireJS handle all the
retry logic. Once it exhausts the list then it can call errback so we can
show a failure message to our users.

Keep up the great work.

Raul

I very much agree with Rail's idea for having an array of locations for a given module that RequireJS can iterate through in failure until all options are exhausted, only then calling the errback.

Alternatively, the errback could receive some sort of input argument distinguishing if all possible paths have been attempted yet.

I still prefer the former, though.

I like Raul's idea of a fallback array at first glance.  That seems to cover the common case and it's cleaner than everyone using a CDN copying each other's boilerplate function template around.  I'd likewise second the motion for the errback function receiving the retry list and current retry state.  Effectively this would mean that require.js would provide a default errback function which could be overridden by users.  This would let users tweak and refine this logic for their needs.  Much like the experience with plugins, generally useful improvements could be factored out for inclusion in require.js' default implementation.

I'd also like to see some clarification on the scope and API footprint of the errback function.  For example, is it only intended to be called on the first require() call (e.g. via data-main's code)?  That implies persistence.  If that's the case, I'd almost prefer specifying it via the config.  Also, what happens if another errback function is supplied by other code later on?  Does it override the original globally?  Or just for that call?

-- John

I have filed this issue to track this request:
https://github.com/jrburke/requirejs/issues/257

My first inclination, if there is a paths array, then no indication of
state in any additional errbacks listed. Although that implies that
there is a way for an errback to indicate "I handled the error, do not
notify other errback listeners for this error", and the paths array
auto-errback wiring would cancel on handling the error.

If anyone wants to comment more on this/follow it, leave a comment in
the bug above.

There can be many error listeners for a given module failure, and they
apply for any module in a given module's dependency tree. As mentioned
above, I think there needs to be a way for an error handler to mention
it has handled the error, so do not keep notifying.

On the config option for an errback: My first thought is that it may
not be needed, the most common case would be to wire fallback urls,
but if that is provided via a paths array support, is that enough?

James