Support for RequireJS config functions about requirejs-rails HOT 3 OPEN

+1

I hit a situation where 'init' in requirejs.yml would have been helpful.

We're using MooTools and jQuery, so we pull in both via requirejs. In addition, we pull in a 3rd AMD'd file for setting up jQuery noConflict, but in case that doesn't get loaded or loaded in the incorrect order, and jQuery gets loaded after MooTools, jQuery retakes/clobbers $.

Would be nice to, on 'init' of jQuery via requirejs, setup the noConflict.

from requirejs-rails.

Personally, I would rather use it just how it is described on the website in javascript. I find trying to 'translate' everything there, which is documented very well, into a another format, which isn't - just adds to complexity and obscurity.

ie. you are saying a con is 'complicated' - but I have no idea that your yaml solution wants and found that more complicated than just reading the documentation on requirejs site. And then if it doesn't support shim for example as you mention, it adds even more complication because devs will be wondering why it just doesn't work.

And the pro definitely is a feature I'd like to see (This will handle more complex RequireJS configurations)

"Cons: More complicated implementation. Not backward compatible. Compatibility issues could be mitigated by adding a deprecation warning and accepting both YAML and JS configuration files for a limited number of pre-1.0 releases."

from requirejs-rails.

"Complicated" means complicated to implement, of course. A stock requirejs configuration is not JSON, which is normally easily handled in most modern languages. It's full-on Javascript, albeit a limited structure, which still requires a full Javascript parser implemented in Ruby. Dealing with JSON or YAML in most dynamic languages is trivial, as they map cleanly to native datastructures. Switching to a parser means that validation, inspection, transformation, then reserialization all must happen via a parser-specific AST.

But all that aside, the YAML approach was great for quickly getting to a usable state but is just as clearly not the way forward as my notes on other issues have stated.

from requirejs-rails.