I created an app using api-only flag, and I ran into a problem.
I wanted to install a gem that includes a mountable engine, in which there are JS/CSS assets. When I mounted the engine, I got an error complaining that the JS/CSS files don't exist.
Rails.application.routes.draw do
if Rails.env.development?
mount SomeGem::Rails::Engine, at: "/some-gem"
end
end
When I tried the same on a new app without the api-only flag, it worked great without any hassle. So I am assuming that the api-only flag is affecting the bundle process (maybe excluding all JS and CSS assets?) but I can't find the relevant information in the doc.
What am I missing?
Well I haven't tried Rails 5 yet but, my general understanding is that API only will allow developers write business logic and won't work well with the view layer. Hence, I think you have chosen the wrong development mode. I suggest if you need to do view related development then, you should remove the flag and try to use it.
I'm trying to use this gem barometer and in the document it says that it can be used right out of the box with using require 'barometer'
I've always used gems and put them in the gemfile, but I think this is different...
Do I just download this entire repo, and copy all the files in the lib folder into my vendor folder? or maybe public folder?
Where would you typically put these files? And where would you include the require? Should this be in the application controller? Or maybe in the helper? Sorry for this really noob question.
I know in my local environment, I can just type in gem install barometer in my console, and not have to put in a require, but I don't think this will work in heroku, or production environment.
I've always used gems and put them in the gemfile, but I think this is different...
No, this is no different. Barometer is a Rubygem and putting it in your Gemfile is exactly the way to use it.
As with every library, your require should go in whichever file uses the code, for example the same file that the Barometer.new call is. You don't always need the require line depending on your Ruby environment, but it's always a good idea to get used to it
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.
We always have ruby gem of famous javascript or css lib such as bootstrap-sass, ember-rails. But for some js lib such as bootstrap-lightbox, there are no gems sometimes. In order to manage these asset automatically, I found the jail(https://github.com/charly/jail) gem. But it seems that project is not so active now. Are there any better solution then just download and past file?
Many of those "assets gems" are just a basic skeleton with js/css assets, it should not be too hard to build your own and publish on rubygems!
An advantage of this, beside locking versions in Gemfile, is that you have control over them and don't risk screwing everything up during a bundle update.
I have found issues using external gems for managing assets, especially with bootstrap ones, sometimes the precompilation will break or they will upgrade the assets inside, breaking the entire site (or minuscole portions that you may hardly notice) with not-so-wanted changes.
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.