I've just updated my Gemfile.
At the beginning I thought problem came from Zeitwerk (from 2.4.2 to 2.5.4) but I've downgraded it and I still have an issue on my spec. I've isolated that the problem does not come from RSpec and dependencies.
Actually, RSpec does not found a class which is defined within another file and does not match the file name/class name.
Important point: Filter::MyStandardError is found.
# app/services/filter/my_standard_error.rb
module Filter
class MyStandardError < StandardError; end
class MySpecificError < MyStandardError; end
# ...
end
# app/services/filter/my_tested_service.rb
module Filter
class MyTestedService
def initialize
raise ::Filter::MySpecificError
end
end
end
RSpec.describe Filter::MyTestedService do
subject { described_class.new }
it 'raises an error'
expect{subject}.to raise_error(::Filter::MySpecificError)
end
end
And I got the error:
NameError:
uninitialized constant Filter::MySpecificError
I got the Changelog but breaking changes are not used on my configuration.
Does anybody have an idea for this one?
You do not need to add app/services to the autoload paths, that is done automatically by Rails. I'd suggest to remove that configuration to keep things simple/idiomatic.
The implementation of app/services/filter.rb should not be needed. Your application is doing something that is not right, we just need to find it.
Could you please delete app/services/filter.rb, throw Rails.autoloaders.log! in config/application.rb, trigger the error, and share the traces?
After reading one-file-one-constant-at-the-same-top-level
I found this to fix my issue
# app/services/filter.rb
class Filter
class MyStandardError < StandardError; end
class MySpecificError < MyStandardError; end
end
# app/services/filter/my_tested_service.rb
class Filter
class MyTestedService
def initialize
raise ::Filter::MySpecificError
end
end
end
I still don't know why it was working before..
You cannot define two constants at the same level in the same file. It is one constant, one file. This has not changed in Zeitwerk upgrades. You need one file for the standard error, and another file for the specific error.
Related
I have these 2 files in a large system, both are located in PackA
people.rb
module People
class HobbyValueObject
end
end
job.rb
module People
class Job
end
class CityValueObject
end
end
I am trying to use CityValueObject in a different module like this,
Module is in PackB
work.rb
module Profile
class Work
....
def calculateTaxes
...
a = People::CityValueObject....
end
end
end
But it's giving me an error saying,
NameError: uninitialized constant People::CityValueObject
Did you mean? People::HobbyValueObject
Why is not being able to fine CityValueObject but can find HobbyValueObject just fine?
How do I make it find the object that I am intending to use?
I am not explicitly declaring any requires or includes
I was able to resolve this by adding require at the top while using full path file name.
require './packs/people/app/public/people/job'
Consider a Rails 6 application that has app/models/application_record.rb. This Rails 6 application is using Zeitwerk loader.
class ApplicationRecord
end
If I want to add functionality to ApplicationRecord via a module:
# app/models/concerns/fancy_methods.rb
module FancyMethods
def fancy_pants
puts "I'm wearing fancy pants"
end
end
and do the following:
class ApplicationRecord
include FancyMethods
end
I will get a deprecation warning or error:
DEPRECATION WARNING: Initialization autoloaded the constant FancyMethods.
Being able to do this is deprecated. Autoloading during initialization is going
to be an error condition in future versions of Rails.
Reloading does not reboot the application, and therefore code executed during
initialization does not run again. So, if you reload FancyMethods, for example,
the expected changes wont be reflected in that stale Module object.
This autoloaded constant has been unloaded.
Please, check the "Autoloading and Reloading Constants" guide for solutions.
(called from <top (required)> at /Users/peter/work/recognize/config/environment.rb:5)
I've read lots of articles including the Rails autoload docs, but nothing really addresses this minimal but common case of extending ApplicationRecord. Yes, I could wrap ApplicationRecord in a .to_prepare block like:
Rails.configuration.to_prepare do
class ApplicationRecord < ActiveRecord::Base
include FancyMethods
end
end
But this seems like a code smell and could cause other unexpected problems now or down the line.
Figured it out! The issue was there was an explicit require in an initializer that loaded ApplicationRecord.
# config/initializers/setup_other_fancy_thing.rb
require 'application_record'
module OtherFancyThing
def also_fancy
puts 'also fancy'
end
end
ApplicationRecord.send(:include, OtherFancyThing)
The way I debugged this was that I:
Created a new Rails app of the same version and could not reproduce the error
I copied the default application.rb and development.rb and still got the error
Moved the entire config/initializers directory to a temp directory and it made the warning go away! So, I knew it had to be one of the initializers. From there it was just a matter of dividing and conquering until I found the offending initializer.
Great! So, basically, you do not need to define the module and include it that way. Idiomatically, you define the module in its own file, normal:
# app/models/other_fancy_thing.rb
module OtherFancyThing
def also_fancy
puts 'also fancy'
end
end
and then
# app/models/application_record.rb
class ApplicationRecord
include FancyMethods
end
Whenever ApplicationRecord is loaded, for example as a side-effect or loading some regular model, it will load FancyMethods just fine.
I've worked with a couple of Ruby gems and also Rails. One thing I've never fully understood is why Rails required explicit class constant references for code defined in the /lib folder. In a ruby gem, I could create something like this:
lib/my_gem/custom_error.rb
module MyGem
class CustomError < StandardError
end
end
lib/my_gem/some_class.rb
module MyGem
class SomeClass
def initialize
raise CustomError
end
end
end
Whether it's an error, another class or whatever, as long as the calling class is in the same namespace as the referenced class, ruby would initialize the correct class CustomError in the case above. Moving to Rails, this is a different story and this code would result in an uninitialized constant error. In Rails I would have to raise MyGem::CustomError instead. Why is this the case? I assume it has something to do with autoloading. Is there a way around this or is this standard?
I'm following instructions at http://ariejan.net/2011/10/14/rails-3-customized-exception-handling/ and have hit a road block.
I am relatively new to rails, so I'm not sure what I've done right/not-so-right.
The first step was to create class
MyApp::ProfileNotFoundError < StandardError
end
So I went to app/models and created profile_not_found.rb which contains the following, where (APP) is the name of my app as defined by Rails.application.class.parent_name, but I have hidden from this post for security/privacy.
(APP)::ProfileNotFoundError < StandardError
end
In app/controllers/application_controller.rb I added
rescue_from (APP)::ProfileNotFoundError, :with => :profile_not_found
and in my login controller I added
raise (APP)::ProfileNotFoundError if #profile.nil?
However, when I try to test the code, I get a Routing Error stating
uninitialized constant (APP)::BlankUsernameError
In my opinion, this suggests that I did something wrong pertaining to the class creation, but the tutorial is so vague I can't figure it out. Any pointers?
I'm running Rails 3.0.20 & Ruby 1.8.7 on Ubuntu 12.04.2 x86_64
Do you have the class keyword in your class definition?
class MyApp::ProfileNotFoundError < StandardError
end
Secondly, you'll have to require your exceptions where you're using it. This is probably the problem you're encountering with the uninitialized constant error. To do this you will probably have to wrap it in a module:
module Exceptions
class MyApp::ProfileNotFoundError < StandardError
end
end
Also, you should put your error classes in a different directory than /models. This directory should be explicitly for your models. Maybe make one like /errors.
Everytime i get a warning:
app/controllers/agency/agencies_controller.rb:1: warning: toplevel constant ApplicationController referenced by Agency::ApplicationController
My agencies_controller.rb:
class Agency::AgenciesController < Agency::ApplicationController
def index
...
end
...
end
And Agency::ApplicationController:
class Agency::ApplicationController < ApplicationController
layout 'agency'
helper_method :current_agency
private
def current_agency
#current_agency ||= current_user.agency
end
end
What the rails wants from me? What is the trouble?
Same situation with another controller
class Agency::ClientsController < Agency::ApplicationController
...
end
And no warnings, no errors...
I realize this question is almost two years old but I recently stumbled upon this through another stackoverflow post and wanted to share some insight.
Basically, if your namespace Agency happens to be a class instead of a module, you'll get that warning. In the stackoverflow post I pasted above, they had a model (class) of Admin and their namespace was also Admin.
This provides a better explanation of what is happening.
So check to see if your code isn't defining an Agency class somewhere. Good luck.
I had similar issues running Spork and Watchr in my Admin namespaced controllers. So i've fixed this by adding following code into each_run block in spec_helper.rb:
Dir[File.expand_path("app/controllers/admin/*.rb")].each do |file|
require file
end
All credits goes to guy from this thread
ApplicationController is the name of the superclass controller that Rails generates for you when you create a new project that all your other controller classes inherit from. There's probably a conflict somewhere because you've used the same name, even though you put it within a namespace.
Try giving your Agency::ApplicationController a different name.
I had similar issues, after setting up Spork and Watchr. In the process, I turned off class cacheing (config_cache_classes => false in config/environments/test.rb) so that changes would be reloaded as necessary in the spork environment. Turning class cacheing back on made the warnings go away.
In my case it was the problem with Devise. I had a devise model Admin and a namespaced routes Admin. Changing the namespaced route to Admins solved the problem.
Solution for me was add this line:
# spec/rails_helper.rb
Dir[File.expand_path("app/controllers/admin/*.rb")].each { |file| require file }