At the moment when I generate a new controller, Rails also generates a .js.coffee file for the controller as well. As I don't use CoffeeScript I want Rails instead generate .js files for me.
Is it enough to comment out the coffee-rails gem to completely disable CofeeScript in a Rails 3.1 app?
Comment out gem "coffee-script" in your Gemfile
Use .js instead of .js.coffee for your javascript files
Not sure if this counts for Rails 3.1 but in 4 you should also set the javascript_engine to :js in application.rb to instruct generators to create .js files instead of .js.coffee.
config.generators do |g|
# .. other configuration ..
g.javascript_engine :js
end
Koen and Gaurav Gupta have good answers!
If you want to make these changes automatically for every new Rails project, you can use a template file.
In ~/rails-template.rb
# Don't install coffeescript
gsub_file 'Gemfile', /^gem \'coffee-rails\'/ do
"\# gem 'coffee-rails'"
end
# Mess with generators to get the behavior we expect around new files
# For these injections, indentation matters!
inject_into_file 'config/application.rb', after: "class Application < Rails::Application\n" do
<<-'RUBY'
config.generators do |g|
# Always use .js files, never .coffee
g.javascript_engine :js
end
RUBY
end
Then in ~/.railsrc
-m ~/.rails-template.rb
Now whenever you run rails new, the coffeescript gem will be commented out, and new controllers will use .js instead of .coffee.
Tested on Rails 5.0.4, but I believe it should work for earlier versions as well.
As an aside, Rails templates, and generators in general, are super powerful. I'm a teacher and my students will typically create 15 to 20 rails projects through the course, and providing them with a good template file with debugging gems, spec style testing, etc. is a huge timesaver. After they've made the changes once themselves, of course. If you're interested, my personal .rails-template.rb is on GitHub.
Note for Rails 4, or if you're using 'turbolinks', 'uglifier', or any other kind of gem that requires the server to interpret javascript, comment them out as well.
I had this problem, as I am using codekit to compile my coffeescript.
I got around it by renaming my 'assets/coffee' folder to 'assets/cafe', so rail wouldn't find it.
Edit: What does work (and the ONLY thing that works for me, the above answer does not work) is to add a separate folder 'App/Coffee', and setting it to be compiled into the assets/javascript folder. If it's in the assets directory, rails will find it no matter the name.
Related
I have upgraded from 3.2 to 4. But assets are broken.
I have been using "assets/img/work/1.jpg" but I can't access to them in this way now. I can only access with digest like "assets/img/work/1-90041f6a6f670bd667cbfb47a50b27d2.jpg" what should i do? Only way is using image_tag?
Is using erb in CSS and JS files cause performance issues?
Append RAILS_ENV=production to rake assets:precompile will bring back the digest in CSS.
Unfortunately, the way that assets works has changed in Rails 4 so that sprockets-rails only generates digested assets. See Changes from Rails 3x for more details.
As commented in this answer, there is a rake task at https://github.com/rails/sprockets-rails/issues/49#issuecomment-20535134 that may be helpful if you need to generate static assets.
I can't comment on performance issues with ERB in CSS and JavaScript. The rails guide implies that using ERB in JS and CoffeeScript is the "Rails Way" of doing what you require. If you are using sass, you can use image-url instead of an ERB file.
I need to use the CSV module built into Ruby 1.9.2, and, in order to do this, I need to do require 'csv'.
In Rails 3, where is the proper place to put this require? I have seen examples where it's at the top of the file it's used in.
I have also see an example where it's put in config/initializers/csv_init.rb.
Is there a rule of thumb here? If I need it in multiple files, put it in an initializer, if only one put it in the file itself?
Put it in 'config/application.rb'. (See "Configuring Rails Applications").
In general, do this stuff in a central place and document it. The person maintaining your application will appreciate it when some future Ruby or Rails version breaks all kinds of backward compatibility.
As the title states, I'm a beginner in Ruby.
My project uses 2 existing gems - which I want to modify.
I've forked the gems on GitHub and put them as modules in my repo and they show up as a subdirectory.
I've tried researching this, but I keep on getting lost - I'm thinking I'm missing some basic concepts/knowledge here.
My questions:
Am I going about this right/wrong?
Is it even possible to include the code of those (forked) gems in my actual project, or should I update them separately and just use them as actual gems with require (this seems very cumbersome)
If these gems are part of my project, how do I use them properly, I assume I don't need the require piece? If not, how do I access/use them?
Thanks!
BTW, using Ruby 1.9.2-p194 on Ubuntu with RubyMine as the IDE.
Probably wrong. Ruby is a very flexible language, and has what are called open classes. This means that you can open up and change classes at run-time. Doing this on an external library is called monkey patching. So instead of having to replicate all of the code you want to stay consistent, you can just modify the classes and override any methods you want.
A simple example:
class Fixnum
def is_multiple_of_three?
self % 3 == 0
end
end
However, if the changes you want are really significant, it could make sense to fork the gem.
I recommend the bundler gem. This will let you make a Gemfile which lists all of your dependencies. You can list a github repository as a source for the gem, like so:
gem 'gem_name_here', :git => 'git://github.com/username_here/gem_name_here.git'
and then run bundle install to install your dependencies.
If you install the gems with bundler, it acts just like any other gem you have installed.
I have recently experienced an issue where I must add the following to my gemfile:
gem 'execjs'
gem 'therubyracer'
I must do this to avoid a javascript runtime error that occurs when starting the rails server. I would like to have this modification added to all new gemfiles created with the rails new command.
You're looking for application templates.
Rails documentation on Application Templates
If you want the option to customize each app individually instead of having a rigid template, a really good option is Rails Composer. It prompts you about common gems during setup, and it nails a lot of the more common gems.
Finally, if you like Rails Composer, but want to be able to re-use application templates, check out Rails Apps Composer. I haven't looked into this too much, but it seems to give you a lot of flexibility while doing most of the heavy lifting for you.
I'm migrating a pre-Rails-3.1 app up to 3.1 (actually, someone else did part of the work of attempting to migrate to 3.0; I'd like to go ahead and get it up to 3.1 now).
When I create a new Rails 3.1 app with rails new, the skeleton app seems fine.
When I run rake test or thin start in the migrated app, though, I get:
/Users/dwhsix/.rvm/gems/ruby-1.9.2-p290#zmy/gems/sass-rails-3.1.0.rc.6/lib/sass/rails/template_handlers.rb:32:in `<class:SassTemplate>': undefined method `default_mime_type=' for Sass::Rails::SassTemplate:Class (NoMethodError)
I think I have things configured correctly. Gems are correct, application.rb has:
config.assets.enabled = true
config.generators.stylesheet_engine = :sass
Is there more that is needed somewhere?
Thanks...
May be please try adding one more at application.rb, since rails 3.1 use scss as default.
config.sass.preferred_syntax = :sass
and there is some mime related settings at initializers/mime_types.rb, so you may try to play with that too.
You could also switch to scss if you wanted to, by using the sass-convert command. I originally used sass syntax, but later decided I liked scss better and switched to that.
sass-convert -F sass -T scss mystyle.sass mystyle.scss
Okay, this turned out to be a problem of having too many versions of various gems installed. The real culprit was the wrong version of tilt, which was being brought in by some other gem. Clearing that, and resetting Gemfile.lock, took care of it.
I had the same problem just now. My solution was to update the tilt gem as described in this github issue. Apparently, the default mime type method, is added after tilt 1.3.0.