I am creating a gem that will contain the foundation-rails gem along w/ some common variables that are used across my applications. I have created a stylesheet at vendor/assets/stylesheets/foundation.scss. I load this from within my application as such
Gemfile
gem 'foobar-foundation-rails', path: '...'
app/assets/stylesheets/application.css
//= require foundation
This is a good starting point but how do I include the foundation-rails gem's stylesheet from within this file? I am unsure how to reference another gem's assets
I think the best approach is to put the responsibility for the require statements in your rails app's javascripts file. This is most likely not functionality you want to bury in a gem, as it hides what is happening.
Then make sure you require your gem's css file before the foundation-rails require. However you should put a dependency requirement in your gem's gemspec file to ensure that the foundation-rails gem will be installed by bundler when your gem is installed.
Also you may have to "namespace" your gems style sheet in order to avoid namespace collisions.
vendor/assets/stylesheets/foobar_foundation_rails/foundation.css
Which would change the require in your stylesheet file to
require 'foobar_foundation_rails/foundation.scss'
Lastly, the naming of a gem establishes how the gem gets required. When you use dashes Rails expects things to be required, and hence your gem's directory structure to follow
lib/foobar/foundation/rails
As opposed to an underscore naming foobar_foundation_rails
lib/foobar_foundation_rails
Unless you're going to build an "extension" to the foundation-rails gem, which would need to be called foundation-rails-foobar, you may want to go with the underscore syntax to save yourself some require headaches. The devise gem is a good example of extension gems.
Related
I'm trying to wrap the bootstrap-sass gem inside another gem (let's call it my-engine). Along the way, I'm building a small Rails application to test things out. As a first step, I wanted to make sure I could get bootstrap-sass working directly in my Rails application. The Gemfile for the Rails app looks like this:
gem 'bootstrap-sass', '3.3.1.0'
gem 'my-engine, path: "~/dev/my-engine"
This works fine. The bootstrap assets are loaded into my Rails application and everything looks good. Now, I want to take bootstrap-sass out of my Rails app and let it load through my-engine. So, my Rails application Gemfile now looks like:
gem 'my-engine, path: "~/dev/my-engine"
The .gemspec for my-engine has:
spec.add_runtime_dependency 'bootstrap-sass', '3.3.1.0'
I can re-bundle the my-engine gem with no problems. I can re-bundle the Rails application with no problems. However, when I refresh the page of the Rails app, I get the following error:
File to import not found or unreadable: bootstrap-sprockets.
That break occurs when sprockets is trying to build the application.css file. Sometimes this will pass and I'll get a different error about missing the bootstrap.js javascript file when the application.js is being built.
Why is this happening? I'm wondering if it has something to with the fact that I'm developing the gems locally and haven't published them, although I'm not sure why that would affect bootstrap-sass which is published. I'm using bundler 1.5.3.
Make sure 'bootstrap-sass' is required in your engine. One sensible place to do this is in your lib/my-engine.rb file:
require 'bootstrap-sass'
Adding the bootstrap-sass gem as a runtime dependency in the .gemspec isn't enough when you're trying to wrap gems.
As you want to use more and more scss/js/coffeescript libraries, you may want to consider moving to bower vs gemfiles as the source for bootstrap-sass-official. We use bower-rails for rake tasks and auto-configuration. It's a really lite config/rake task layer over standard bower.
Addressing your answer, bootstrap problems via the gem was one of the reasons I switched our engine over to just bower assets. We now import bootstrap-sass-official and have full control, note however that for sass files you will need to import the longer path to the source file, i.e. in our engine _application.scss:
# our custom variable overrides
#import 'overrides/variables';
#import 'bootstrap-sass-official/assets/stylesheets/bootstrap-sprockets';
#import 'bootstrap-sass-official/assets/stylesheets/bootstrap';
NOTE: if you want your app sass variables to override engine and sass variables, make sure your engine has _application.scss not application.scss, the leading underscore is critical for variable context/scope.
Thinking ahead, you may need to ignore bower transitive dependencies as we did.
(i.e. some dependencies may use 'bootstrap' while others use 'bootstrap-sass-official' etc)
We use it like this in our .bowerrc such as the following:
{
"ignoredDependencies": [
"bootstrap",
"bootstrap-sass",
"bootstrap-sass-official"
]
}
In conclusion
We have been using this for several months with success. bower-rails will install the dependencies in /vendor/assets and if referenced in your engine, you won't need to reference them at all in your application project. It has been fast and easy to maintain/add/update libraries and know exactly how files are included.
I am developing a Rails app where most of the code not specific to the app has been written inside of various gems, including some Rails engines and some 3rd party gems for which I am enhancing or fixing bugs.
gem 'mygem', path: File.expath_path('../../mygem', __FILE__)
Since a lot of the code in these gems is really part of the app, it's still changing frequently. I'd like to be able to utilize the Rails feature where code is reloaded on each request when in development (i.e. when config.cache_classes is false), but this is only done within the normal application structure by default.
How can I configure Rails to reload gem code on each request, just like with the app code?
I have found through trial and error that several steps are required, with the help of ActiveSupport.
Add activesupport as a dependency in the .gemspec files
spec.add_dependency 'activesupport'
Include ActiveSupport::Dependencies in the top-level module of your gem (this was the most elusive requirement)
require 'bundler'; Bundler.setup
require 'active_support/dependencies'
module MyGem
unloadable
include ActiveSupport::Dependencies
end
require 'my_gem/version.rb'
# etc...
Set up your gem to use autoloading. You an either manually use ruby autoload declarations to map symbols into filenames, or use the Rails-style folder-structure-to-module-hierarchy rules (see ActiveSupport #constantize)
In each module and class in your gem, add unloadable.
module MyModule
unloadable
end
In each file that depends on a module or class from the gem, including in the gem itself, declare them at the top of each file using require_dependency. Look up the path of the gem as necessary to properly resolve the paths.
require_dependency "#{Gem.loaded_specs['my_gem'].full_gem_path}/lib/my_gem/myclass"
If you get exceptions after modifying a file and making a request, check that you haven't missed a dependency.
For some interesting details see this comprehensive post on Rails (and ruby) autoloading.
The solution that I used for Rails 6, with a dedicated Zeitwerk class loader and file checker :
Add the gem to the Rails project using the path: option in Gemfile
gem 'mygem', path: 'TODO' # The root directory of the local gem
In the development.rb, setup the classloader and the file watcher
gem_path = 'TODO' # The root directory of the local gem, the same used in Gemfile
# Create a Zeitwerk class loader for each gem
gem_lib_path = gem_path.join('lib').join(gem_path.basename)
gem_loader = Zeitwerk::Registry.loader_for_gem(gem_lib_path)
gem_loader.enable_reloading
gem_loader.setup
# Create a file watcher that will reload the gem classes when a file changes
file_watcher = ActiveSupport::FileUpdateChecker.new(gem_path.glob('**/*')) do
gem_loader.reload
end
# Plug it to Rails to be executed on each request
Rails.application.reloaders << Class.new do
def initialize(file_watcher)
#file_watcher = file_watcher
end
def updated?
#file_watcher.execute_if_updated
end
end.new(file_watcher)
With this, on each request, the class loader will reload the gem classes if one of them has been modified.
For a detailed walkthrough, see my article Embed a gem in a Rails project and enable autoreload.
I have a ruby gem and I want to use the Hash.from_xml method in the gem that is included in rails active_support module. I have the below code in my gemspec:
gem.add_dependency 'active_support', '~> 3.0.0'
However, when I build and install the gem locally, run irb, require the gem, I am not seeing the methods from active support included?
Any suggestions on what I am doing wrong or how to debug? Thanks!
You need to require the methods you need from ActiveSupport; they aren't added by default.
As Yevgeniy mentioned in a comment, the way to do this is require 'active_support/all' if you need everything - or if, for example, you want only the Hash extensions then use require 'active_support/core_ext/hash'. Note that this usually doesn't go in the gemspec, but rather in whatever file your gem uses to set itself up.
Perhaps even better would be to require the required ActiveSupport files in the actual files needing them, but that's a matter of taste.
I installed the Redactor gem, but after some time I decided that this gem doesn't suit my needs. I removed it from Gemfile, and also removed all of the gem's files (I suppose) in all app folders.
When I try to deploy app, the server fails to start with this error:
uninitialized constant Redactor Rails
It points to the folder which I actually removed (in models). Each time it is created while I'm pushing the app to the server (with git).
How can I completely remove ALL the files that the gem generated?
You sure did
gem uninstall redactor-rails
Remove in your application.js
//= require redactor-rails
also in your application.css
*= require redactor-rails
The gem also generated in
app/uploaders/redactor_rails_document_uploader.rb
app/models/redactor_rails/document.rb
I'm building a gem locally, suppose it name is "MyGem".
Now suppose that MyGem depends on other already built gem, for example "cancan".
So, i've added in my mygem.gemspec the line:
add_runtime_dependency("cancan")
Here is the problem: if I installl MyGem into a new project by adding it into my gemfile like this:
gem "mygem", :path => "path/to/my/local/gem"
then this new project is not being able to use cancan methods, and I have to explicity declare cancan on the new project gemfile in order to use it.
I tried also using gemspec method, but didn't solve my problem either.
Any ideas?
Update
I just wanted to add that when i only have myGem declared in my new application gemfile, after I run bundle install all the dependencies are installed.
That is, if i run gem list the "cancan" gem is displayed, but I still can't access it methods from the application level.
Thanks for the help.
Ok, i've solved this. I'm not sure if this is the best solution but it did work.
Making the application level developer to explicity add the dependencies in his gemfile didn't make any sense. So, as the gems did were being installed, i just required all the gem dependencies in my my_engine.rb file inside my gem.
Following the example, in my my_engine.rb I added the following line
require "cancan"
And that'it...
Even better you could do:
autoload :CanCan, "cancan"
So the module would be loaded only when it is called.
And even better than that, you could load only the file from cancan that you are using (maybe you don't need to load all of it).
You can add that line in you my_gem.rb file or your engine.rb file if you are using engines.
That worked for me, I hope this help someone.
Use add_dependency instead of add_runtime_dependency (this may help with cancan) then run bundle update on your new project.
Does the "cancan" gem name actually match the name to be require'd?
Example for yajl-ruby gem:
Gem::Specification.new do |s|
s.name = %q{yajl-ruby}
...
But when require'ing the library, you'd use a different string:
require 'yajl'
That means in your Gemfile, you have to explicitly require the dependency (which you said you wanted to avoid).
gem 'yajl-ruby', '>=1.0', :require => 'yajl'
To avoid needing to do this, and if you're the author of the "cancan" dependency, you should make the gem name matches the require name.
The only alternative I can think of is require'ing the dependency directly in one of your source files (like you did in your solution).