I'm using Rails with Propshaft and using cssbundling-rails to compile sass.
I'm having an issue where some SVG's referenced from a node-module are not displaying.
I'm rather confused as to the difference and purpose of lines such as Rails.application.config.assets.paths << Rails.root.join("------") in config/initialisers/assets.rb and manifest.js in app/assets/config.
Please can someone explain the difference and what I need to put in both. This hopefully may help me to track down my missing assets problem.
Thanks
Related
Basically, I am in the same boat as this question:
Rails 4 asset compilation is VERY slow (>1min) in dev mode. How to troubleshoot?
But instead of using Bootstrap, I'm using Susy 2 with SASS 3.3 and Rails 4.1 (but not Compass). I'm using the Sprockets 'require' in my application.js manifest, and it's not causing any problems...the snail's pace only happens when I make a change to any SASS file. At the moment I'm needing to use the #import rule in my stylesheet manifest.
I have tried variations on the 'require'/'#import' combination, and they have helped a little bit, but I do have a lot of SASS files and I'd love to just have an application.css.scss manifest that uses SASS's compilation method instead of including a 'global' file with an #import at the top of each SASS file.
I'm wondering whether it could have something to do with the current Sprockets/sass-rails gem issues; during compilation I get a lot of
Warning. Error encountered while saving cache 6b6acdc6a4d802b749fef26e565bbfe3caa60193/style.css.scssc: can't dump anonymous class #<Class:0x007ff59c2c8870>
I'd try moving back to SASS 3.2 if I could and still use Susy 2.
I'd be OK with not using the Asset Pipeline if I could be sure that the app would still play nice with Heroku when pushing to staging/production. I am familiar with both Grunt and Gulp, less so with what using Grunt/Gulp instead of the AP would do to my Rails app.
On the one hand, I'm glad that I'm not alone with this problem, but on the other...I'd love to find a way out of it, if anyone has some suggestions to share! Thanks in advance, SO community!
The issue here is that I have Bootstrap on production looking for the fonts at:
assets/spree/fonts/glyphicons-the-file-name.something
When in development mode, it looks for these assets in:
fonts/glyphicons-the-file-name.something
So what I did was I added the fonts folder into public and it all worked. I did the same for production. You can guess that I'm now dealing with a rails assets:clean issue that must be running and removing the files, hence not allowing them to appear.
Is there a way to tell Rails to not clean the files in assets/spree/fonts?
I'm assuming you installed the bootstrap files manually?
If you instead use a gem such as the following, then you won't have to worry about these issues:
gem "bootstrap-sass"
Alternatively, you should be installing everything into your vendor directory. As you've found you'll then have issues with any linked assets within these files. The correct fix for this would be to edit the bootstrap source to use the correct asset_path helpers.
Obviously that's quite a bit of maintenance overhead when you get round to doing the next bootstrap update.
I'd take a look at the bootstrap-sass gem, even if you decide not to use it.
In section 2.2.2, "CSS and Sass", I'm told to put image-url('delete.png') in my sass. And so I have.
However, it is generating CSS like
background-image: url(/images/delete.png)
instead of the thing that I'm told everywhere it should be generating, the correct and obvious thing,
background-image: url(/assets/delete.png)
What. The heck.
I have spent literal days trying to figure out where this is coming from.
Here's a gist of relevant settings that are resulting in this behavior. Here's a gist of the same files in an earlier version of our code base (right after we implemented the asset pipeline and it actually worked for about a week before this frustrating behavior popped up). Can you spot the differences? Any other files you can think of that might be causing this?
Note
We're purposely using an older version of sass-rails because a newer version was causing Stack level too deep! errors when precompiling.
We're using Compass.
Two hackish attempts at workarounds
Because actually troubleshooting the asset pipeline kinda sucks.
1: Put images in /images
I attempted to just move all of the images to public/images and add that as a load path. This worked in dev (images are accessible at either /assets or /images), but precompiling for production puts the fingerprinted images in /assets only (obvs), so when sass-rails puts in url(/imagse/delete-120398471029384102364.png), it can't be found.
2: Make /public/images a symlink to /public/assets
This would probably work in production, but in development the /assets folder doesn't exist, so the url(/images/delete.png) directives result in unfound images.
If you do not have this already, name your css file *.css.scss (as opposed to .sass - if you do this, you might need to adjust the syntax of some statements). Then use the image_path helper instead of image-path, e.g.:
background-image:url(image_path('delete.png'));
I expect this to solve your issue. If it does not, what is the asset path generated by this approach for you?
This looks to be due to your version of sass-rails (3.1.0). I can reproduce your problem (thanks for posting the Gemfile) and it goes away when bumping to sass-rails 3.1.4.
Try upgrading to 3.1.4 and clearing tmp/cache. Also make sure you're not hitting any browser caches.
I know you said 3.1.4 was causing other problems... have you tried higher versions?
It really looks like this issue: https://github.com/rails/sass-rails/issues/57
If so you should try to find the good combination of versions between Compass and Sass-rails.
And maybe upgrade everything (Rails included) to latest versions, it's still the best way to do (use bundle outdated command in bundler 1.2 to know what Gems to upgrade)
This is our combo of haml-rails, compass and sass-rails. We're running rails 3.2.6 though.
This has worked well for us.
gem 'compass', git: 'git://github.com/chriseppstein/compass.git', ref: '3a4c5c75dca9f07f6edf2f0898a4626269e0ed62'
gem 'haml-rails', git: 'git://github.com/indirect/haml-rails.git', ref: '92c41db61f20a9f122de25bc73e5045cfccdbcd5'
gem 'sass-rails', '~> 3.2.5'
Not necessarily a solution, but certainly an available option: If you're open to using compass spriting, you'll cut down on the number of http requests and be able to manually specify your image path with a sprite map, ie '$sprites: sprite-map("PATH/*.png");'
Sanity check the file in your current asset pipepline. Check that it's in one of the directories listed in here:
<%= debug Rails.application.config.assets.paths %>
Next check at what relative path compass expects to find the image ( and see if it mat. According to the Compass config docs, one of these should tell you:
<%= debug config.compass.http_images_path %>
<%= debug config.compass.http_generated_images_path %>
I'm guessing it's the first one. Either way, compare their path to your image's asset_path:
<%= debug asset_path 'delete.png' %>
If the paths don't match, maybe you need to adjust the path in your environment configs (development.rb, ...) to this for example:
config.compass.http_images_path = '/assets.
Alternatively, you could move the image to where http_images_path or the http_generated_images_path expect to find it.
At the point, asset_path/asset_url (which are much less brittle than hardcoding) should hopefully work. I based this off of a similar technique I saw for stylesheets,
For me,
Changing image_path to image-path worked for .scss. Later on, I changed to image_path again and it's working fine now.
Deleting cache didnt help me.
After I edited my .scss file (added a space) and reload the page I got right result. After I removed the space it worked correctly.
I have the following files, in my asset path:
javascripts/abc.js
templates/abc.js.mustache # this gets compiled to abc.js
naturally, they both would be requested as assets/abc.js.
Is there a fix? If not, what part of the Sprockets source would need to be modified?
My thinking is along the lines that if the engine can remove the extension, it can well enough add a suffix.
It may be too obvious, but isn't it better just rename files? I understand nature of your question, but it's hard to imagine ultimate requirements, which forces same filenames for those files. Hence this, you have foobar.js and foobar.js.mustache, which compiles to foobar.js. Why they have same names? They do same things? This is design flaw, if you ask me.
I have the same problem, and have not yet found a satisfying solution. My sites have many complex full-stack plugins (aka engines), and they have lots of css, js, and image files. Having to namespace, eg "styles.css" in each plugin kinda sucks. When upgrading to Rails 3, I assumed the file resolver would put engines/plugins in /styles, but no, they all get combined into one virtual path.
My current temporary solution is to build a rake task that I run that checks for duplicate filenames. I run it before committing code and on deployment. Hackity! If that helps, great, if not, perhaps someone out there has a more elegant solution...
I'm trying to use these gists to get Sprockets 2.0beta to work with a Rails 3.0.5 app in a similar way to how it works natively in Rails 3.1. Failing thoroughly so far--my app is finding the correct routes and files, and loading the initializer that extends Sprockets::Environment, but it's not parsing the //= require 'phu' lines in my application.js.
Can anyone enlighten me about Sprockets 2 with Rails 3.0?
I have used the same gists as a basis, and it works fine. I have made some changes though.
Maybe you can try that, see if it helps: https://gist.github.com/1112393
ps: I guess you solved it yourself since it's been a month...
I personally have another problem: How to use Sprockets 2 with Rails 3.0.x (how to use precompiled assets)
If you solved it already, or found another way to make this efficient on production, could you help me? Thanks.