Is there any known way to run the js-routes gem on Heroku? The trouble seems to stem from the fact that the routes can't be compiled when the App isn't mounted (because it needs access to the Rails routes), but Heroku won't let you set initialize_on_precompile = true in order to make that possible. I'd really like to use the gem though... I predict it'll save me a ton of trouble down the line. Any ideas?
I use workaround. Pre-generate routes in dev env.
Add js routes into development group in Gemfile.
Then fix initializer:
if defined?(JsRoutes)
JsRoutes.setup do |config|
config.include = [/item/]
config.default_url_options = {:locale => I18n.locale}
end
end
Then run rake js:routes to generate js file.
And finally add app/assets/javascripts/routes.js into repo
Related
I have a complex Rails app and I want to extract some core functionality into an engine so that I can reuse the models etc in other Rails apps.
I've been following the official documentation for engines (https://guides.rubyonrails.org/engines.html). I'm able to create a new engine inside the app and generate some test models
> rails plugin new testengine --mountable
testengine> rails generate model Test
This is the .gemspec
require_relative "lib/testengine/version"
Gem::Specification.new do |spec|
spec.name = "testengine"
spec.version = Testengine::VERSION
spec.authors = ["Me"]
spec.summary = "testengine"
# Prevent pushing this gem to RubyGems.org. To allow pushes either set the 'allowed_push_host'
# to allow pushing to a single host or delete this section to allow pushing to any host.
spec.metadata["allowed_push_host"] = "TODO: Set to 'http://mygemserver.com'"
spec.files = Dir["{app,config,db,lib}/**/*", "Rakefile", "README.md"]
spec.add_dependency "rails", "~> 6.1.4"
end
I console into the test dummy rails app in testengine, and I can find my new model at Testengine::Test, no problem. So far so good.
Now I get to section 4.1 Mounting the Engine. I add the engine via the Gemfile file (in fact this is already done for me thanks to the rails generator above).
gem 'testengine', path: 'testengine'
Then I install my gems without problems.
> bundle install
...
Using testengine 0.1.0 from source at `testengine`
...
I console into the main app and I can find Testengine and Testengine::VERSION but not Testengine::Engine or Testengine::Test.
Reading a little further the docs say you need add this line to config/routes.rb
mount Testengine::Engine, at: "/testengine"
I do and now the rails app won't even start
config/routes.rb:3:in `block in <top (required)>': uninitialized constant Testengine::Engine (NameError)
What did I miss?
I will answer my question for the benefit of others who might make the same mistake I made. In my case, gem 'testengine', path: 'testengine' was buried inside a group of gems e.g. in
group :test do
...
end
I guess I was confused how rails loads gems from groups and missed the detail about group inclusion. It seems that while it'll show in the list during bundle install, and autoload some basic items, such as Testengine::VERSION it doesn't autoload everything unless you are running an environment as the same name as the group. In hindsight, this seems a bit obvious. Lesson learned.
I'm making a gem that executes Rails commands (rails g model Item for example). When I use it in a Rails project, everything works. The problem is testing it in development outside of a Rails project.
I'm using cucumber with aruba to test if CLI commands execute the proper rails commands and generate the expected files. Unfortunately, when I try to test the behaviour it fails because there are no rails files and the commands require to be run inside of a Rails project in order to work.
I have added a rails dependency to the gemspec:
Gem::Specification.new do |spec|
spec.add_development_dependency 'rails', '~> 5.2.4'
end
I've thought about creating a new rails project on test start and then deleting it after the tests run, but that seems highly inconvenient. Is there a better way to do this?
A technique we use for WickedPDF is in the default rake task, before we run the tests, is to delete & generate a full Rails application in a gitignored subdirectory of the gem.
As a high-level simplified example of this Rakefile, it looks something like this:
Rakefile
require 'rake'
require 'rake/testtask'
# This gets run when you run `bin/rake` or `bundle exec rake` without specifying a task.
task :default => [:generate_dummy_rails_app, :test]
desc 'generate a rails app inside the test directory to get access to it'
task :generate_dummy_rails_app do
if File.exist?('test/dummy/config/environment.rb')
FileUtils.rm_r Dir.glob('test/dummy/')
end
system('rails new test/dummy --database=sqlite3')
system('touch test/dummy/db/schema.rb')
FileUtils.cp 'test/fixtures/database.yml', 'test/dummy/config/'
FileUtils.rm_r Dir.glob('test/dummy/test/*') # clobber existing tests
end
desc 'run tests in the test directory, which includes the generated rails app'
Rake::TestTask.new(:test) do |t|
t.libs << 'lib'
t.libs << 'test'
t.pattern = 'test/**/*_test.rb'
t.verbose = true
end
Then, in test/test_helper.rb, we require the generated Rails app, which loads Rails itself and it's environment:
test/test_helper.rb
ENV['RAILS_ENV'] = 'test'
require File.expand_path('../dummy/config/environment.rb', __FILE__)
require 'test/unit' # or possibly rspec/minispec
# Tests can go here, or other test files can require this file to have the Rails environment available to them.
# Some tests may need to copy assets/fixtures/controllers into the dummy app before being run. That can happen here, or in your test setup.
You could skip parts of Rails that aren't needed by customizing the command that generates the app. For example, your gem may not need a database at all or a lot of things by default, so you command could be customized for a simpler app. Something like this maybe:
system("rails new test/dummy --skip-active-record \
--skip-active-storage --skip-action-cable --skip-webpack-install \
--skip-git --skip-sprockets --skip-javascript --skip-turbolinks")
In the WickedPDF project, we wanted to test across a wide range of "default" Rails installs, so we don't customize the command much, but that may generate much more than what you need to test some generator tasks.
WickedPDF also tests against multiple versions of Rails with TravisCI and multiple Gemfiles, but this could also be accomplished with the Appraisal gem that Luke suggested in this thread.
Check out Thoughbot's Appraisal gem:
Appraisal integrates with bundler and rake to test your library against different versions of dependencies in repeatable scenarios called "appraisals."
Here is a guide on how to set it up, including setting up a micro Rails app within your tests dir.
I've been writing Rails apps for so long that I'm suddenly stuck with something you get for free with Rails: environments.
That is to say, you can run the Rails app locally and by default, RAILS_ENV (or Rails.env) is "development". And if you are running your specs/tests, it's "test" and when you deploy to your production server, you set it up to run as "production".
This is particularly useful when you have config files. Also useful for the Gemfile to differentiate gems for certain environments.
So now to my question: I'm writing a pure Ruby app and I don't know the best way to set it up so that I can still have the multiple environments? I want to set up config files for 3rd-party services (like MongoLab/Iron.IO/etc.) but I want them set up with "development", "test", "production", etc. And then I want to be able to run the app from various environments.
I know I could just manually handle it via command-line environment variables, but I'm wondering if there are best (better?) practices for this? Any gems that help with this? Or any recommendations for how to structure environment handling for a pure Ruby app?
Thanks,
You could do something quite like the way rails does it:
class AppEnvironment
def initialize(env = :production)
#name = env.intern
end
def development?
#name == :development
end
def test?
#name == :test
end
def production?
#name == :production
end
end
app_environment = AppEnvironment.new( ENV['APP_ENVIRONMENT'] )
Then you set the environment var via rake tasks.
namespace :myapp do
desc "Run a development server"
task :server => :environment do
ENV['APP_ENVIRONMENT'] ||= "development"
# ...
end
desc "Run a bunch of tests"
task :test => :environment do
ENV['APP_ENVIRONMENT'] ||= "test"
# alternatively do this in `spec_helper.rb`
end
end
Added.
Using different sets of gems per environment is pretty easy with Bundler.
You might recognize this line from config/application.rb in rails:
Bundler.require(:default, Rails.env) # Rails.env is just a string
This tells bundler to require all gems in a specific group in addition to gems declared outside a group.
gem 'foo'
group :test do
gem 'rspec'
end
If you are just talking about config files, you can just use a setup that looks like Rail's database.yml file, read it in and select the "right" set of variables.
There is also at least one gem to deal with such "multi-level" config files.
Use ENV['RACK_ENV']. RAILS_ENV is actually just a copy of it.
Use other ENV's to manage your dependencies. For example, credentials and configs can be stored in ENV's.
Some ENV's are typically stored in a config file, like database.yml or mongoid.yml.
You can use the dotenv gem to manage your local ENV's. However, I prefer to have a Ruby or shell script that sets the ENV's and/or starts the server in development environment:
local_setup.rb:
ENV[ 'RACK_ENV' ] = 'development'
or
rackup_local.sh:
RACK_ENV=development rackup
You can use a similar script for the test config and require it in the spec helper. I prefer to add the configs to the top of the spec helper.
If you put secrets in your env script, be sure to Git ignore it and do not add it to your repo.
Regarding the Gemfile, it is not a good idea to use different gems for different environments unless there is a good reason to do so. Testing, debugging and caching are good examples for being in an environment group in the Gemfile.
If I call url_for within a feature spec, it returns an absolute URL starting with http://www.example.com/. Capybara will happily attempt to load pages on that site, but that has nothing to do with my app. Here are minimal steps to reproduce the issue:
Start with this Gemfile:
source 'https://rubygems.org'
gem "sqlite3"
gem "jquery-rails"
gem "draper"
gem "rails", '4.1.0'
gem "therubyracer"
gem "uglifier"
gem "rspec-rails"
gem "capybara"
gem "poltergeist"
gem "launchy"
Run the following:
bundle
rails new myapp -O
cd myapp
rm Gemfile Gemfile.lock
rails generate controller Test test
rails generate rspec:install
mkdir spec/features
Comment out the lines in spec/spec_helper.rb that say they should be removed when not using ActiveRecord, and then create spec/features/feature_spec.rb with the following contents:
require 'capybara/poltergeist'
Capybara.configure do |config|
config.javascript_driver = :poltergeist
end
require 'spec_helper'
describe "nothing", js: true do
specify do
visit(url_for(controller: :test, action: :test))
save_and_open_page
end
end
Finally, run rake spec and you will see the example.com page pop up in a browser. I have verified this behavior back to Rails 3.2.17.
Why is this happening, and is there a way to get URLs for the app being tested instead of example.com?
Edit: some things I have found looking into this more:
ActionDispatch::Routing::UrlFor.url_for is called from RSpec examples. It has only_path defaulting to false.
ActionView::RoutingUrlFor is the version you get in, say, a view. It has only_path defaulting to true, which works much better.
This commit to the rspec-rails gem probably caused the problem, by adding www.example.com as the default host. There is no explanation anywhere about why this host is an appropriate/useful choice.
The problem manifests for the following reasons:
You are using Poltergeist, which uses PhantomJS, which is perfectly capable of opening any URL.
You are using the url_for helper which needs to know the domain it should be generating a url for. When used inside a Rails view or controller, Rails supplies the domain based on what was used to make the request. When outside of a view or a controller, like in an ActionMailer or Capybara test, the domain is unknown. Capybara defaults the unknown domain to example.com.
So everything is working the way it should. Now, it happens to not be the way that you want it to work. However, if you want it to work how you would like you should do one of the following things:
Use the path_only option in url_for to tell it not to use the host part.
Use the host option in url_for to specify the correct host.
This is how those gems work. The http://example.com is irrelevant to your app. In general, you should not have fully hard-coded paths in your app. Rails attempts to determine your local domain (for specs this is example.com, which is configurable) and creates paths off of that.
The idea here is that you have a base URL which may change. Say, for staging I use a Heroku local app: randomname-123-staging.heroku.com. My urls will be prefixed with that. However, in production I own a domain name. My urls there will start with mydomain.com. It makes no sense for me to have to update all of my URLs based on the environments base domain; this should be (and is) provided by Rails.
By using a generic domain, which is supposed to be guaranteed to not resolve to a real IP, the specs help you code to this possibility.
What do you do when you want to use a gem for development/testing that you don't want to force other devs to use? Right now I have
begin
require 'redgreen'
rescue LoadError
end
in test_helper.rb and no gem config, but that seems like a clumsy approach, albeit a functional one. I'd like to do something like the following:
config.gem "redgreen", :optional => true
Any other suggestions? Or should I just vendor those pretty superficial gems...?
EDIT
To be clear, I am only talking about those specific gems, like redgreen, which aren't actually used in the functional code, but only in the coding process. There is no need to vendor these at all, except to avoid the conditional require.
Gems that are specific to your development environment should be installed in your gemset or local gems, but not in the Gemfile.
A classic example is the ruby-debug-base19x which Rubymine needs for debugging. This is installed in your local gemset, but not in the Gemfile because not all coders use Rubymine.
[EDIT]
Indeed, everything is run in the context of the bundle, and outside gems are not reachable. There do exist some workarounds indeed. Most of them are dirty :)
I found a lot of good solutions in this bundler issue.
The nicest solution was to add this to your .irbrc :
# Add all gems in the global gemset to the $LOAD_PATH so they can be used even
# in places like 'rails console'.
if defined?(::Bundler)
global_gemset = ENV['GEM_PATH'].split(':').grep(/ruby.*#global/).first
if global_gemset
all_global_gem_paths = Dir.glob("#{global_gemset}/gems/*")
all_global_gem_paths.each do |p|
gem_path = "#{p}/lib"
$LOAD_PATH << gem_path
end
end
end
require 'irb/completion'
require 'rubygems'
require 'wirble'
Wirble.init
Wirble.colorize
If you then install wirble to the global gemset, it can then be found.
Original source: https://gist.github.com/794915
Hope this helps.
I answered a similar question of my own here
User-level bundler Gemfile
One way to do this is to create different environments:
group :scott do
end
Then
bundle --with-env=scott
Ok, I think I've come up with something. Basically, the idea is to only execute a secondary Gemfile when a Rails app is executing. To do this we add two things:
First, we alter the rails script a little:
# in ./script/rails
Kernel::IN_RAILS_APP = true
APP_PATH = File.expand_path('../../config/application', __FILE__)
require File.expand_path('../../config/boot', __FILE__)
require 'rails/commands'
Second, we tell bundler to pull in the secondary Gemfile if we're in a rails app and a secondary file exists:
# Gemfile
if Kernel.const_defined?(:IN_RAILS_APP)
local_gemfile = File.dirname(__FILE__) + "/Gemfile.local"
if File.exists?(local_gemfile)
puts 'using local gemfile'
self.instance_eval(Bundler.read_file(local_gemfile))
end
end
Now you can add a Gemfile.local to your project and run specific gems on a per-machine basis. bundle install works normally since the IN_RAILS_APP constant doesn't exist.
** Make sure to add Gemfile.local to your .gitignore.
In my opinions this is what environments are for. Fortunately there is also a way provided to do it with what is in your Gemfile, this is also how rails use it: groups
Pretty much use the environments the same way rails use it. Here is what you could find in your Gemfile:
group :test do
# Pretty printed test output
gem 'turn', :require => false
end
And here is what you can find in your config/application.rb
Bundler.require(:default, Rails.env) if defined?(Bundler)
All you would need to do is to change your local environment settings and the others working with you won't be affected unless they decide to. Everything gets committed and nothing gets lost.
Here some links :
http://yehudakatz.com/2010/05/09/the-how-and-why-of-bundler-groups/
http://gembundler.com/groups.html
If you want it to be optional, it's better to freeze the gem as a plugin. However, it's not a good idea to use different gems than the rest of a development team, as it creates some inconsistencies in the codebase that can be hard to track down later. I would say add it to config.gem, and just tell the other developers to do:
rake gems:install
And you're done.
This is how I tackled the same problem under Rails 3.1. In my Gemfile:
if File.exists? './tmp/eric_dev_gems'
gem 'redgreen'
gem 'awesome_print'
gem 'wirble'
gem 'wirb'
gem 'hirb'
end
Create a file in ./tmp/ (or in some folder which is in your .gitignore) of your choosing. I used eric_dev_gems. This should be ignored by git, and will only exist on your system unless one of your teammates decides he wants to create that file too.
I solved it by putting this in my gem file:
$gem_names ||= ENV['GEM_PATH'].split(':').map{|g| Dir.glob("#{g}/gems/*").map{|p|p.split('/gems/').last}}.flatten
gem 'redgreen' if $gem_names.any?{|n| n=~/redgreen/ }
That way the gem will only be used if you manually installed it on your system.
This works well but has the downside that it puts the gem name in the Gemfile.lock. This is of little consequence because the gem does not get installed with bundle install but it does make your lock file a bit messy and can cause the lock file to change a bit from one developer to the next.
If that is an issue for you another option is to keep the gemfile clean and require the gem by its full path, or you can add the path for just that gem. Like this:
$gem_paths ||= ENV['GEM_PATH'].split(':').map{|g| Dir.glob("#{g}/gems/*")}.flatten
$gem_paths.grep(/redgreen/).each {|p|$LOAD_PATH << p+'/lib'}
require 'redgreen' rescue nil