Support hosted library importing

[jwhitley]

Just like you can do "jquery" : "empty:" as a path in your r.js build file and then have the hosted url in your main.js (like https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js), I'd like to have requirejs-rails do that.

http://requirejs.org/docs/optimization.html#empty

[jwhitley]

Thanks for filing this issue. My initial take for this is to simply recognize any paths matching /^https?:/ and automatically swap them out for empty: in the build configuration. Another approach would be to allow separate user configs for run vs. build time... but I think I'll wait on that until I have some concrete use cases in hand.

[btaitelb]

I started working on a patch for this last night, but had a difficult time figuring out the meaning of various variables (like the relationship between build_config and basConfig), where to put the logic for adding 'empty:' and where to put the logic for setting the path.

In terms of my use case, I'd want it to be as simple as putting the following into requirejs.yml:

paths:
  jquery: https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js

If you can help me understand the build_config method, I'd love to write some unit tests for it, so I can work on this in a TDD style.

[jwhitley]

Second use case related to CDN support, from offline conversation with @stammy:

The ability to specify baseUrl on a different domain for use in various environments. This allows for entire sets of built assets hosted in the cloud, for example using tools like the asset_sync gem. For example:

baseUrl: "http://www.mybigcdn.com/192bac214/assets"

Current design proposal is to allow config/<environment>/requirejs.yml files, loaded only at runtime, and which override the settings from the master config. This will mean the master will tend to be the default development and build config, while production, staging, etc. settings can specialize as needed.

[stammy]

Thanks @jwhitley -- I like your proposal for environment based requirejs.yml files.

[btaitelb]

Are there other gems that follow the multiple config file approach? It seems too cluttered to me. I would suggest either allowing access to the configuration at runtime (so someone can use initializers for custom per-environment configuration), or allowing erb in the yml file so you can have some per-environment logic right in the yml file.

[stammy]

"or allowing erb in the yml file so you can have some per-environment logic right in the yml file."

My initial thought was to have a ruby initializer file so I can use my ENV vars that have my environment-specific CDN urls and so on.

[jwhitley]

Completely agreed. ERB or config via an initializer it is.

@btaitelb Thanks for the heads-up on #build_config needing docs/tests. I'm planning on tackling this on Monday, so I'll get a round of tests and docs in place. This highlights an approach that requirejs-rails has taken that needs some clarification. There's a lot of overlap in require.js' config-at-runtime vs config-at-build-time, it's rather non-DRY but generally easy to automate.

To this end, a fair bit of effort in the gem has been to ensure that build configuration follows by-convention rules (e.g. buildUrl: "/assets") so that users can just run rake assets:precompile and get on with life. Those policies have been evolving rapidly but are definitely ready to be documented. In fact, the push to 1.0 is really just a big pile of docs bugs.

[jwhitley]

@stammy @btaitelb I've just landed the CDN changes on master. Please look over the new docs covering the two cases in this issue at External domain (CDN) support.

[btaitelb]

This is great! It provides a nice simple interface to something that always felt a little hacky in requirejs. Thanks!

[jwhitley]

Thanks for the feedback. This has just been released as 0.8.0.

@stammy Please let me know how the documented support for the everything-hosted-on-a-CDN works out for you. I haven't had the time to do ad-hoc testing with this, as I'm not currently setup for CDN publishing. If you don't get to it, I'll try to get asset_sync setup sometime this week.

[stammy]

@jwhitley awesome!! Will try to test it out tomorrow and report back. Yeah I'd test asset_sync with it too and push to our staging.