13

In Rails 3.1, Sprockets are used to manage assets and package them into a single file. Which, in general, is not such a bad idea.

As quoted from an external source, which explains the issue at hand:

A problem with this approach is that it could make debugging harder, if you have to look at the "concatenated" CSS file in production to make sense of what code's included and not, it's harder to know what comes from where than if you just included the original source code files.

One solution would be to have a way to switch between "concatenated" and "normal" modes easily (maybe it's already possible, I don't know), so that normal development would be unimpeded. But you'd have to resort to the big concatenated file for debugging in production.

In Rails 3.0.X, our designer could easily pin-point the CSS setting using Firebug, which will indicate the file and line number directly, since all CSS files were separate and not packaged into one.

Or am I missing the point?

Douglas F Shearer
  • 25,952
  • 2
  • 48
  • 48
Christian Fazzini
  • 19,613
  • 21
  • 110
  • 215
  • Deleted my answer, went back and look at a Rails 3.1 app I have, the files are concatenated in development, just not compressed. Looking at the source there is no flag to disable this behaviour. Perhaps this might be something that is worth creating a ticket for on Rails' Github Issues. I had a quick search and couldn't see anything similar. – Douglas F Shearer May 24 '11 at 20:45
  • Actually, since Rails 3.1 expects my default that you should be using SCSS and CoffeeScript, the outputted files are not going to be the same as the source anyway. I remember seeing talk of someone creating a Firebug plugin for SCSS and coffeescript, was a few weeks back though. – Douglas F Shearer May 24 '11 at 20:46
  • I do think it's an issue. I've seen Jammit suggested as an alternative to Sprockets because Jammit serves up separate files in development. – Alex Korban May 24 '11 at 21:01
  • Hi Douglas. Came across a plugin called Firesass. I think this is what you were intending. On a side-note, Would be nice if Rails 3.1 natively gives the option to not concatenate files in dev mode, to make debugging easier in the development stage – Christian Fazzini May 24 '11 at 21:21

6 Answers6

13

You can also use :

<%= stylesheet_link_tag "application", :debug => Rails.env.development? %>
<%= javascript_include_tag "application", :debug => Rails.env.development? %>

The files will not be concatenated in development but will in other environments.

Sucrenoir
  • 2,994
  • 1
  • 27
  • 31
5

Add ?debug_assets=true to any URL you want to debug. It splits the assets into their parts. Without it, concatenation happens according to your environment settings.

Harry Love
  • 1,920
  • 1
  • 25
  • 25
  • I think this is the easiest solution to debug assets, actually it's what I do, instead of modifying layout file (and commit the debug symbol accidentally) I prefer using the debug option in the URL which makes more sense and much faster – kalbasit Sep 14 '11 at 17:49
3

I think in the end (when the RC gets closer/becomes a release) you will be able to modify your config/application.rb with the following config.assets.css_compressor = false

But, atm, that doesn't really fix it since the stylesheet_asset_tag helper function isn't exactly compatible with the new pipeline and the :all modifier doesn't work, so...

In your application.html.erb view you will have to link each css

<%= stylesheet_link_tag "stylesheets/application" %>
<%= stylesheet_link_tag "stylesheets/foo" %>
<%= stylesheet_link_tag "stylesheets/bar" %>

As long as you have config.assets.enabled = true in your config/application.rb the root of assets will be (by default) /assets

You can fire up a rails console (rails c) and p Rails.application.assets to see the properties that are configurable in the mean time.

I agree not the best solution, but at this point (using an RC vs a stable release) its the best way I've found.

UPDATE: Digging around the edge api, found this ActionView::Helper sprockets_stylesheet_link_tag (http://edgeapi.rubyonrails.org/classes/ActionView/Helpers/SprocketsHelper.html) but it seems to be still an incomplete replacement for stylesheet_link_tag since it doesn't support :all and you still have to have the stylesheets/ segment in your function call. With that said, its prolly the function to use moving forward, so...

<%= sprockets_stylesheet_link_tag "stylesheets/foo" %>
colinross
  • 2,075
  • 13
  • 10
1

You can also use :

<%= stylesheet_link_tag "application", :debug =>true%>
<%= javascript_include_tag "application", :debug => true %>

It Will gives you following output in view source of your browser

 <link href="/assets/application.css" media="screen" rel="stylesheet" type="text/css" />
 <script src="/assets/jquery.js?body=1" type="text/javascript"></script>
 <script src="/assets/jquery_ujs.js?body=1" type="text/javascript"></script>
 <script src="/assets/application.js?body=1" type="text/javascript"></script>
Hitesh
  • 815
  • 1
  • 6
  • 11
  • Pushing this to production will likely break things. Better to use @Sucrenoir's approach above which effectively sets debug to true only while developing. – Eric D. Fields May 31 '13 at 16:37
1

I found an interesting issue. If I precompile assets (to commit into git), test in production mode, and then go back to using a development environment on the same machine, I see this problem.

Even though I'm back in development mode, the contents of public/assets are being cached and served instead of fresh asset contents. So here's how I fixed it:

rm -rf public/assets
Brock Adams
  • 90,639
  • 22
  • 233
  • 295
Excalibur
  • 3,258
  • 2
  • 24
  • 32
0

sprockets probably will work only in production environment, there's no need to package everything into a single file during development and test

x0rist
  • 625
  • 4
  • 9