I've used jammit to do my asset packaging so far, but my next application will be in Rails 3.1
Should/Can I still use Jammit? Or should I work with the built-in asset pipeline?
You can still use Jammit, but the built in asset pipeline is The Rails Way™.
I'd recommend you try out the asset pipeline/Sprockets - if you don't like it, it's as simple as moving the javascript and css files back to the public directory and setting up Jammit the old way.
I found that setting up the asset pipeline the first time around for browser specific css was a little non-intuitive, but, that was just me being unfamiliar with the whole process. Sprockets works well and allows you to use ERB/HAML with your coffee script or sass (if you want.)
Related
I need to use my sass stylesheets for another non-rails site (a Wordpress blog), so I need to compile them into a css file without the file fingerprinting from the asset pipeline. I saw this related post:
Rails 4 Asset Pipeline: Compile both with and without fingerprint
However, it doesn't seem to give me the non-fingerprinted stylesheet I'm looking for
Rails 4 has documentation for this.
Just set
config.assets.digest = false
in your environment configuration file (for example config/environments/production.rb)
http://guides.rubyonrails.org/asset_pipeline.html#turning-digests-off
There is a gem called non-stupid-digest-assets which allows you to determine which files are "fingerprinted" and which are not.
#config/initializers/non_digest_assets.rb
NonStupidDigestAssets.whitelist = ["your_file.js"]
You'll then be able to call it your_file.js as well as using asset_path asset_path("your_file.js")
I'v seen some larger emberjs implementations like discourse: https://github.com/discourse/discourse/tree/master/app/assets/javascripts/discourse
Can someone explain to me how this gets integration into rails?
What happens behind the scenes when the asset gets compiled? To the files just get minified and merged or there is more to it?
You need to read about Asset Pipeline.
The directory you linked to above is included by the various require lines in app/assets/javascripts/main_include.js, which is itself included by app/assets/javascripts/application.js.erb.
The gem doing the heavy lifting (the one responsible for interpreting the require lines) is Sprockets.
What happens behind the scenes when the asset gets compiled? To the files just get minified and merged or there is more to it?
Between the asset pipeline docs and sprockets' docs, your very general question should be more than answered. In a nutshell, yes, the files are minified and merged, and yes there is a whole lot more to it.
In addition to reading about the Asset Pipeline and Sprockets (which handle JS minification, etc), also take a look at the ember-rails gem: https://github.com/emberjs/ember-rails
ember-rails allows you to include Ember.JS into your Rails 3.1+ application. The gem will also pre-compile your handlebars templates when building your asset pipeline. It includes development and production copies of Ember.
I'm serving a semi-static site with rails, just to get used to rails conventions.
Do I really need to use the asset pipeline to serve the .css and .js?
I could always precompile my .scss and coffee-script before their on the server.
and by semi-static, I mean that I may include some gems to do syntax highlighting or some other little tasks.
I guess it would be good practice?
I'm super new to rails and programming in general, by the way.
I just want another opinion.
Thanks, in advance.
You should use the asset pipeline if you are using rails 3.1 or above. It is far faster than the previous serving of assets in rails -- among other things, it munges and minifies the files.
You should always precompile your assets in production, whether or not you are using straight .css or .scss because if you don't precompile your assets, rails will still have to compile them at runtime.
I just upgraded my project to rails 3.1 since I saw the sass feature and the moving of public folder files to the assets folder and considered these major changes I should adjust to, especially the sass feature which is pretty cool.
however, when looking at heroku, i came across this post detailing what to do to get rails 3.1 working on heroku: http://devcenter.heroku.com/articles/rails31_heroku_cedar#getting_started
my app hasn't launched yet but I do intend to be on heroku and from the looks of that document, getting rails 3.1 to run on heroku sounds a little messy, where the assets folder is being created in the public folder.. when it has its own place now in 3.1.
what are everyone else's thoughts on this? i like to keep my code clean and am thinking if I should go back to rails 3.0.
maybe I missed something or a useful reason for doing this here, or am not interpreting this right, because this public folder precompile thing sounds so redundant to me.
In short, is having Rails 3.1 on Heroku good? Or should I go back to Rails 3.0
The asset pipeline is not required, and you can simply not use it if you don't want to.
Definitely keep Rails 3.1 for your app. You will have a much easier time upgrading for things you like in the future, and will have better security updates as the older versions eventually won't be maintained.
I'd recommend using the asset pipeline, and you can read more about it in the guide. http://guides.rubyonrails.org/asset_pipeline.html
If you don't want to use it though in your config/application.rb file change:
config.assets.enabled = true
to
config.assets.enabled = false
You'll probably also want to remove the assets gem group from your Gemfile as well.
Having your assets compiled into public is nothing to worry about. This is a sensible idea as you don't want to have to recompile your assets for every request.
Rails 3.1 has a number of advantages, however ultimately it's your decision, but I certainly wouldn't be fretting about asset compilation.
If youre app if using Jquery-UI (jquery being the new default in 3.1) then for sure just disable the asset pipeline and use 3.1. asset pipeline breaks jquery-ui anyway.
Because a jQuery plugin I use in my application has direct references to images, I'm trying to turn off asset fingerprinting.
So I set config.assets.digest = false in my production.rb, but now none of my image references work at all. /assets/foo.png just returns a blank response.
I really don't want to alter the jQuery plugin's code and add erb image helpers, but I'm not sure what else to do. And frankly, the asset fingerprinting for images seems to be much more trouble than it's worth.
Does anybody have any insight?
Thanks!
Someone made a gem for this purpose:
https://github.com/spohlenz/digestion
The asset pipeline is a great new component of Rails 3.1. However it
has a feature known as fingerprinting that makes it impossible to
properly incorporate many popular JavaScript libraries (including
TinyMCE, CKEditor and FancyZoom to name just a few) into the asset
pipeline.
This gem patches the asset pipeline to allow these libraries to be
used, by disabling the fingerprinting functionality for specific files
or paths.
If you are using a large plugin, like ckeditor, then your only real option is to move that plugin into the public directory.
For smaller plugins you can move their images into the correct asset path. For example if your plugin references images/icon.jpg under the plugin folder this would need to be moved to something like app/assets/images/plugin_name/icon.png and then referenced in the plugin with <%= asset_tag('plugin_name/icon.png') %>.
The pipeline IS worth it. Not using digests in production pretty much negates the point of using it at all, which is to set far-future headers so that the asset gets cached somewhere.
If you are set on removing digests then you must precompile the assets (so that Sprockets does not serve them with far-future headers), and make sure no headers are set on the server.