-
Notifications
You must be signed in to change notification settings - Fork 202
Investigate implementation of r.js as Sprockets compressor #9
Comments
John, We're currently thinking about using this gem of yours. Out of curiosity, do you have an ETA on when r.js support will be included? (PS to answer your question from the require.js google group: I don't see any reason to support the sprockets directives. Require.js AFAICT allows all the flexibility necessary to include things in the project. TBH, the only thing I don't like about the Rails Asset pipeline is the separation of the javascript across 3 areas of the project (app/assets, lib/assets and vendor/assets). IMHO, all the client-side stuff should drop off one directory in the project.) |
HI Andrew, I'm currently working on this FT, expecting the 0.5.0 release within the next week. That will have precompilation support via r.js, with r.js configuration parameters (paths, modules, etc.) passed in via The roadmap is to let it bake out for a short period and tackle any really critical (or really easy) issues that arise, then bump it 1.0. You can investigate the current state of things on the
Thanks for the feedback re: Sprockets directives. I've come to the same conclusion as I've gotten further into this project. While one certainly could use Sprockets directives in the current implementation, it's really a lot cleaner to manage dependencies entirely via AMD. |
Is the Will the build profile (e.g. app.build.js) go in as a file in app/assets/javascripts? I'm not sure what you mean by Sprockets' aggregated digest. I looked online and in my project and didn't see anything named digest. Is this the app.build.js file or a file built automatically by sprockets for each of the concatenated/uglified/minified script files that go to production? I found some files with occurrences of the term "hexdigest", but I didn't really understand what purpose they serve. Is it to fingerprint the files to see which ones have changed for caching purposes? I definitely agree that it is a lot cleaner to manage dependencies entirely via AMD. While I like peanut butter in my chocolate and vice versa. I prefer to keep my ruby out of my javascript and vice versa. (Excuse me if any of the questions above sound dumb. I'm kind of new to build scripts and deploying.) |
+1 I can't wait for the 0.5.0 release! |
Implementing r.js as a Sprockets compressor turns out to be neither possible or necessary for the requirejs-rails precompilation. Closing this issue. Current ETA for 0.5.0 release by EOD Thursday; just pending critical docs updates and a bit of final shakeout testing. |
@malandrew I ended up leaving |
Cool deal. Why did it turn out not to be necessary or possible? Can't the sprockets recompilation just call r.js directly? |
HI @malandrew, The problem (and about 80% of the work for 0.5.0) comes down to the impedance mismatch between Sprockets and r.js:
Long story short, when it comes to producing a suite of built assets, Rails+Sprockets and r.js compete head-to-head. r.js is far and away the preferable solution for folks using require.js, so the gem's policy is to delegate all build responsbilities to r.js. That said, requirejs-rails does integrate with and use some Sprockets features, particularly the asset paths arrangement. Among other things, this means that any gem that provides JavaScript assets (ala |
Actually, the way you described the way it needs to be done is how I expected it to work. Delegating everything to r.js to me is preferable because it is has the greatest separation of concerns and also is the most portable solution. The only thing I would expect sprockets to do is tell r.js which build file to run (e.g. development, test, production). I'm honestly not a huge fan of Sprockets' c-preprocessor like approach. Less coupling between the require.js client and sprockets also means that there is room to go possible switch some or all of the backend to node.js in the future and leave rails serving legacy API content. IMHO, the javascript assets are already too intertwined with how rails works already. Only when the client and server are running the same language (e.g. node), does it make sense to have them tightly coupled. I'll take a look at 0.5.0 when it's out and also jburke's experimental branch. Thanks! |
On the road to the 0.5.0 release, I've noticed that it may be possible to do a somewhat clean implementation of r.js as a Sprockets compressor. This issue tracks research along those lines, and an implementation if deemed appropriate.
The text was updated successfully, but these errors were encountered: