Most likely you run rake and your code is causing an exception which is not the one shown in your terminal.
Rails tries to catch this exception and clean up constants but -- while it's still booting up -- fails on this which causes another exception:
rake aborted!
cannot remove Object::ClassMethods
Running rake with the --trace parameter will give you no love; the backtrace is useless in most cases.
Try these approaches:
First: Check if there is a helpful error message
- Have a look at the environment's log file instead
- Open up a Rails console (may give you more information than the logs)
If you're lucky it's a helpful message, like a missing database. Unfortunately, the error often is too generic and you don't know where it originates from.
If that won't work: Dig really deep
In any case, Rails usually breaks on the blame_file! call where it tries to show you the source of the error. You can (temporarily) hack Rails' require call in .../gems/activesupport-2.3.12/lib/active_support/dependencies.rb and show the error before Rails gets it into its hands:
def require(file, *extras)
if Dependencies.load?
Dependencies.new_constants_in(Object) { super }
else
super
end
rescue Exception => exception
puts "ERROR: '#{exception}' in #{file}" # This is new.
exception.blame_file! file
raise
end
When you rake --trace after that you may see some "no such file to load" issues (which usually stay hidden) but should also see the file causing the actual error.
Related cards:
Adding Jasmine JavaScript specs to a Webpack(er) project
The goal is to get Jasmine specs running in a Rails project using Webpacker, with the browser based test runner. Should be easily adaptable to a pure Webpack setup.
Step 1: Install Jasmine
yarn...