details_cache_key already references Template::Types.symbols and view
resolvers cache based on default_formats and other values. This
previously wasn't an issue because no views had been looked up before
this was set. Now that we are building a regex from the values of
Template::Types.symbols we need to clear cache after changing this
setting.
Errors *should* output their stack. Somehow these tests were passing
before. This clarifies all states (skip/fail/error) and works against
@tenderlove's patch.
This reverts commit 0f9249c93f402d276730fcfaba1ed1b876ee7c26.
Reverted because this wasn't warning in custom jobs and therefore
applications may have not seen the deprecation. We'll need to fix the
deprecation to warn for custom jobs so that applications can migrate.
Register a callback that will get called right after generators has
finished.
This is useful if users want to process generated files.
For example, can execute an autocorrect of RuboCop for generated files
as like following.
```ruby
config.generators.after_generate do |files|
system("bundle exec rubocop --auto-correct " + files.join(" "), exception: true)
end
```
This makes test file patterns configurable via two environment variables:
`DEFAULT_TEST`, to configure files to test, and `DEFAULT_TEST_EXCLUDE`,
to configure files to exclude from testing.
These values were hardcoded before, which made it difficult to add
new categories of tests that should not be executed by default (e.g:
smoke tests).
It uses environment variables instead of regular Rails config options
because Rails environment is not available when the Runner builds the
list of files to test (unless using Spring). A nicer solution would be
making sure that the Rails environment is always loaded when the runner
starts. This is a first simple step to make these paths configurable for
now
This way at least you could override defaults in `config/boot.rb`:
```ruby
ENV["DEFAULT_TEST_EXCLUDE"] = "test/{dummy,smoke,system}/**/*_test.rb
```
Co-authored-by: Jeremy Daer <jeremydaer@gmail.com>
In the past, we sometimes hit missing `Symbol#start_with?` and
`Symbol#end_with?`.
63256bc5d7a8e812964d
So I proposed `Symbol#start_with?` and `Symbol#end_with?` to allow duck
typing that methods for String and Symbol, then now it is available in
Ruby 2.7.
https://bugs.ruby-lang.org/issues/16348
Using `String#starts_with?` and `String#ends_with?` could not be gained
that conveniency, so it is preferable to not use these in the future.
Previously, a test runner argument had to contain a forward slash to be
recognized as a path. Now, backslashes will also be considered,
enabling the use of Windows-style paths.
Fixes#38243.
Mandrill's Inbound API checks to see if a URL exists before it creates
the webhook. It sends a HEAD request, to which we now return a 200 OK
response to indicate that the route exists.
Now we can generate inbound API calls with ease on Mandrill, without
having to shuffle around tokens in production.
Fixes#37609.
`url_for` will now use "https://" as the default protocol when
`Rails.application.config.force_ssl` is set to true.
Action Mailer already behaves this way, effectively. This commit
extends that behavior application-wide.
Closes#23543.
These were removed in 74201c3885ae2e33bfff046d503324fd1d7a320f when the
template for the 6.0 new framework defaults initializer was deleted.
While we no longer generate the file, upgrading applications will still
have it, so it's still important to check that these options can be set.
I introduced this pattern of referencing a constant to trigger lazy load
hooks in 458a5502a17ccf58d5708a3b030ac9917a0a8476, and it arrived at its
current form via c98a641ff402d3ca5b754f4621a0764f33eab155 and
c24be369322b9e0211fcef30003375de195ef660.
I now realise autoloading doesn't need to be involved at all; we can
require the files that trigger the lazy load hooks directly.
* Add a way to deliver inbound emails by source
Great for testing when you get an eml file and can just paste it in.
* Test updates
* Fix tests
* Fix spacing
* require, require_relative, load by double quotes
We're getting rid of all single quote usage, unless it serves a specific purpose, as per the general style guide.
The `rails test` command scans its arguments for test paths to load
before handing off option parsing to Minitest. To avoid incorrectly
interpreting a `-n /regex/` pattern as an absolute path to a directory,
it skips arguments that end with a slash. However a relative path ending
in a slash is not ambiguous, so we can safely treat those as test paths.
This is especially useful in bash, where tab completing a directory
leaves a trailing slash in place.
With a multiple database application `db:rollback` becomes problematic.
We can't rollback just the primary, that doesn't match the behavior in
the other tasks. We can't rollback a migration for every database, that
is unexpected.
To solve this I handled `db:rollback` the same way I handled `:up` and
`:down`. If `db:rollback` is called for a multi-db application then it
will raise an error recommending you use `db:rollback:[NAME]` instead.
Calling `db:rollback:primary` or `db:rollback:animals` will rollback
the migration for the number of steps specified.
Closes: #38513
Follow-up to: #34078
This method was jumping through extra hoops to find the name of the
class the connection is stored on when we can get it from the connection
itself. Since we already have the connection we don't need to loop through the
pools.
In addition, this was using the wrong class name. The class name for the
schema migration should come from the connection owner class, not from
the `db_config.name`. In this case, `db_config.name` is the name of the
configuration in the database.yml. Rails uses the class name to lookup
connections, not the db config name, so we should be consistent here.
While working on this I noticed that we were generating an extra schema
migration class for `ActiveRecord::Base`. Since `ActiveRecord::Base` can
and should use the default and we don't want to create a new one for
single db applications, we should skip creating this if the spec name is
`ActiveRecord::Base`. I added an additional test that ensures the class
generation is correct.
If I had had these tests previously I would have not created PR #38658
and then promptly realize I needed to revert it.
We need to load and parse the configurations twice. Once before the
environment is loaded to create the named tasks and once after the
environment is loaded to have the real configurations. The configs
loaded before the env have the ERB stripped out and aren't valid
configs.
I have so. many. regrets. about using `spec_name` for database
configurations and now I'm finally putting this mistake to an end.
Back when I started multi-db work I assumed that eventually
`connection_specification_name` (sometimes called `spec_name`) and
`spec_name` for configurations would one day be the same thing. After
2 years I no longer believe they will ever be the same thing.
This PR deprecates `spec_name` on database configurations in favor of
`name`. It's the same behavior, just a better name, or at least a
less confusing name.
`connection_specification_name` refers to the parent class name (ie
ActiveRecord::Base, AnimalsBase, etc) that holds the connection for it's
models. In some places like ConnectionHandler it shortens this to
`spec_name`, hence the major confusion.
Recently I've been working with some new folks on database stuff and
connection management and realize how confusing it was to explain that
`db_config.spec_name` was not `spec_name` and
`connection_specification_name`. Worse than that one is a symbole while
the other is a class name. This was made even more complicated by the
fact that `ActiveRecord::Base` used `primary` as the
`connection_specification_name` until #38190.
After spending 2 years with connection management I don't believe that
we can ever use the symbols from the database configs as a way to
connect the database without the class name being _somewhere_ because
a db_config does not know who it's owner class is until it's been
connected and a model has no idea what db_config belongs to it until
it's connected. The model is the only way to tie a primary/writer config
to a replica/reader config. This could change in the future but I don't
see value in adding a class name to the db_configs before connection or
telling a model what config belongs to it before connection. That would
probably break a lot of application assumptions. If we do ever end up in
that world, we can use name, because tbh `spec_name` and
`connection_specification_name` were always confusing to me.
Follow-up to #38463.
By isolating ARGV, we guard against commands inadvertently depending on
prior ARGV contents. Any such command will now behave consistently when
run via `Rails::Command.invoke`, whether coming from the Rails CLI or
from library code. Likewise, any ARGV mutations done by a command will
not affect code that executes after `Rails::Command.invoke`.
A .ruby-version file is not useful in a plugin dummy app because the
plugin itself dictates the required Ruby version. Indeed, the dummy app
.ruby-version file might fall out of sync with whatever the plugin
dictates, and thus result in unexpected "Could not find gem" errors when
running commands from within the dummy app directory.
When is use a scaffold_controller add the routes as resources to the
config/route.rb
Also enable to use --skip-routes if doesn't want include the resources
into the config/routes.rb file.
The schema cache tests test the following scenarios:
1) The default case works (single db, primary spec name (dev is default
to primary in 2-tier config), standard default schema cache filename)
2) Primary always wins over other entries
3) A custom schema cache filename works when set in the configuration
4) A custom schema cache filename works when set in the ENV
Cases that don't work:
1) A non-primary database entry picks up a namespaced schema cache file
This can't work currently because there's no way of knowing which cache
we actually want. In this railtie we can only load ActiveRecord::Base's
schema cache. If we grab the first config we risk loading a cache for
another connection because order is not guaranteed.
2) Multi-db schema caches
The reasons are similar to above. In addition we can't loop through the
configs, establish a connection, and load the cache because we don't
know what parent class to establish a connection to. In that case AR
Base will always get the cache and it would cause the last one to win
and therefore be loaded on the wrong connection.
The real fix for these issues is to get rid of the railtie entirely, but
for now we needed to set this back to what the behavior was before
recent changes but with the ability to pass a custom key.
Co-authored-by: Katrina Owen <kytrinyx@github.com>
When generating applications, it initializes Git repository since
8989a5057b
However, it doesn't initialize Git when creating plugins.
Plugins are mostly libraries and are likely hosted on GitHub,
so initializing Git for plugins makes sense.
The initializer that loads the default schema cache on the default
connection doesn't account for the case where an app overrides the
default filename either via ENV["SCHEMA_PATH"], or via the
:schema_cache_path defined in the db config.
Note that as discussed in #34449 this initializer doesn't work for
applications using multiple databases, and this change doesn't fix that.
Introduce benchmark generator to add benchmarks to Rails applications.
The generator makes use of `benchmark-ips`, and will automatically add
the gem to the Gemfile as needed.
Co-authored-by: Gannon McGibbon <gannon.mcgibbon@gmail.com>
When generating a new app without `--skip-spring`, caching classes was
disabled in `environments/test.rb`. This was implicitly disabling caching
view templates too. This change will enable view template caching by adding
this to the generated `environments/test.rb`:
config.action_view.cache_template_loading = true
See 65344f254cde87950c7f176cb7aa09c002a6f882
Database configurations are now objects almost everywhere, so we don't
need to fake access to a hash with `#default_hash` or it's alias `#[]`.
Applications should `configs_for` and pass `env_name` and `spec_name` to
get the database config object. If you're looking for the default for
the test environment you can pass `configs_for(env_name: "test", spec_name:
"primary")`. Change test to developement to get the dev config, etc.
`#default_hash` and `#[]` will be removed in 6.2.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
This change addresses a few issues:
First, shelling out to the `rails` command requires the destination
directory to contain certain files that the command uses to initialize
itself. While this is not an issue when running generators normally, it
is troublesome when testing generator-invoking generators which output
to ephemeral destination directories.
Second, shelling out to the `rails` command is very slow. This also is
not a particular concern when running generators normally, but it makes
test suites for generator-invoking generators painfully slow.
Third, shelling out to the `rails` command fails silently by default.
Such silent failures can be surprising, and can lead to confusing
downstream failures.
The Gemfile offers more flexibility than the gemspec in terms of gem
groups and platforms. Putting the default development dependencies in
the Gemfile encourages users to add their own development dependencies
to the Gemfile. This is similar to the current behavior of the
`bundle gem` command (see bundler/bundler#7222).
This change also fixes a corner case where using the "--skip-gemspec"
and "--skip-active-record" options together would incorrectly generate a
"sqlite3" dependency in the Gemfile.
While trying to fix#16433, we made the middleware deletions always
happen at the end. While this works for the case of deleting the
Rack::Runtime middleware, it makes operations like the following
misbehave.
```ruby
gem "bundler", "< 1.16"
begin
require "bundler/inline"
rescue LoadError => e
$stderr.puts "Bundler version 1.10 or later is required. Please update your Bundler"
raise e
end
gemfile(true) do
source "https://rubygems.org"
git_source(:github) { |repo| "https://github.com/#{repo}.git" }
gem "rails", github: "rails/rails"
end
require "action_controller/railtie"
class TestApp < Rails::Application
config.root = __dir__
secrets.secret_key_base = "secret_key_base"
config.logger = Logger.new($stdout)
Rails.logger = config.logger
middleware.insert_after ActionDispatch::Session::CookieStore, ::Rails::Rack::Logger, config.log_tags
middleware.delete ::Rails::Rack::Logger
end
require "minitest/autorun"
require "rack/test"
class BugTest < Minitest::Test
include Rack::Test::Methods
def test_returns_success
get "/"
assert last_response.ok?
end
private
def app
Rails.application
end
end
```
In the case ☝️ the ::Rails::Rack::Logger would be deleted instead of
moved, because the order of middleware stack building execution will be:
```ruby
[:insert, ActionDispatch::Session::CookieStore, [::Rails::Rack::Logger]]
[:delete, ::Rails::Rack::Logger, [config.log_tags]]
```
This is pretty surprising and hard to reason about behaviour, unless you
go spelunking into the Rails configuration code.
I have a few solutions in mind and all of them have their drawbacks.
1. Introduce a `Rails::Configuration::MiddlewareStackProxy#delete!` that
delays the deleted operations. This will make `#delete` to be executed
in order. The drawback here is backwards incompatible behavior and a new
public method.
2. Just revert to the old operations. This won't allow people to delete
the `Rack::Runtime` middleware.
3. Legitimize the middleware moving with the new `#move_after` and
`#move_before` methods. This does not breaks any backwards
compatibility, but includes 2 new methods to the middleware stack.
I have implemented `3.` in this pull request.
Happy holidays! 🎄
The main interface to eager loading is config.eager_load. The logic that
implies happens during the boot process.
With the introduction of Zeitwerk, application code is loaded in the
finisher as everything else, but in previous versions of Rails users
could eager load the application code regardless of config.eager_load.
Use cases:
* Some gems like indexers need to have everything in memory and would
be a bad user experience to ask users to conditionally set the eager
load flag.
* Some tests may need to have everything in memory and would be a bad
experience to have the flag enabled globally in the test environment.
I personally feel that the contract between this method and the entire
eager loading process is ill-defined. I believe this method is
essentially internal. The purpose of this patch is simply to restore this
functionality emulating what it did before because rethinking the design
of this interface may need time.
Fixes https://github.com/rails/rails/issues/28827.
The steps to reproduce are as follows:
git clone git@github.com:bbuchalter/rails-issue-28827.git
cd rails-issue-28827
bundle install
bin/rails db:create
Observe that we create two databases when invoking db:create: development and test. Now observe what happens when we invoke our drop command while using DATABASE_URL.
DATABASE_URL=sqlite3://$(pwd)/db/database_url.sqlite3 bin/rails db:create
As expected, the development environment now uses the DATABASE_URL. What is unexpected is that the test environment does not.
It's unclear what the expected behavior should be in this case, but the cause of it is this: 9f2c74eda0/activerecord/lib/active_record/tasks/database_tasks.rb (L494)
Because of each_local_configuration, there seems to be no way invoke these database rake on only the development environment to ensure DATABASE_URL is respected.
The smallest scope of change I can think to make would be to conditionalize this behavior so it does not get applied when DATABASE_URL is present.
Rails::Configuration::Generators provides method_missing based accessor.
The following code sets `orm` value:
Rails.application.config.generators.orm :data_mapper
The following code does NOT return `orm` value:
Rails.application.config.generators.orm # => {}
It's better that the reader returns the value set by writter in terms of
consistency:
Rails.application.config.generators.orm # => :data_mapper
- ### Problem
ActionPack requires "action_view/base" at boot time, this
causes a variety of issue that I described in detail in #38024.
There is no real reason to require av/base in the
ActionDispatch::Debugexceptions class.
### Solution
Like any other components (such as ActiveRecord, ActiveJob...),
ActionView::Base shouldn't be loaded at boot time.
Here are the two main changes needed for this:
1) Actionview has a special initializer that needs to run
before the app is fully booted (adding a executor needs to be done
before application is done booting)
63ec70e700/actionview/lib/action_view/railtie.rb (L81-L84)
That initializer used a lazy load hooks but we can't do that anymore
because Action::Base view won't be triggered during booting process.
When it will get triggered, (presumably on the first request),
it's too late to add an executor.
------------------------------------------------
2) Compare to other components, ActionView doesn't use `Base` for
configuration flag. A lot of flags ares instead set on modules
(FormHelper, FormTagHelper).
The problem is that those module depends on AV::Base to be
loaded, as otherwise configuration set by the user aren't applied.
(Since the lazy load hooks hasn't been triggered)
63ec70e700/actionview/lib/action_view/railtie.rb (L66-L69)
We shouldn't wait for AB::Base to be loaded in order to set these
configuration. However, we need to do it inside an
`after_initialize` block in order to let application
set it to the value they want.
Closes#28538
Co-authored-by: betesh <iybetesh@gmail.com>"
We missed these in rails/rails#38005 because deprecation warnings are
silently swallowed by these tests.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
When rails is configured to use a specific primary key type:
```
config.generators do |g|
g.orm :active_record, primary_key_type: :uuid
end
```
Previously:
$ bin/rails g migration add_location_to_users location:references
The references line in the migration would not have `type: :uuid`.
This change causes the type to be applied appropriately.
Co-authored-by: Dermot Haughey <hderms@gmail.com>
Enabling `SameSite` cookie protection is an addition to CSRF protection,
where cookies won't be sent by browsers in cross-site POST requests when set to `:lax`.
`:strict` disables cookies being sent in cross-site GET or POST requests.
Passing `:none` disables this protection and is the same as previous versions albeit a `; SameSite=None` is appended to the cookie.
See upgrade instructions in config/initializers/new_framework_defaults_6_1.rb.
More info [here](https://tools.ietf.org/html/draft-west-first-party-cookies-07)
_NB: Technically already possible as Rack supports SameSite protection, this is to ensure it's applied to all cookies_
This change deprecates config in dbconsole and updates usage in the
dbconsole tests so that we can remove an accessor on the
`configuration_hash`.
Eventually we want to pass objects around everywhere instead of
hashes. Callers can use `db_config` to access the hash if necessary.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
- ### Problem
```ruby
MyJob < ApplicationJob
before_enqueue { throw(:abort) }
after_enqueue { # enters here }
end
```
I find AJ behaviour on after_enqueue and after_perform callbacks
weird as they get run even when the callback chain is halted.
It's counter intuitive to run the after_enqueue callbacks even
though the job wasn't event enqueued.
### Solution
In Rails 6.2, I propose to make the new behaviour the default
and stop running after callbacks when the chain is halted.
For application that wants this behaviour now or in 6.1
they can do so by adding the `config.active_job.skip_after_callbacks_if_terminated = true`
in their configuration file.
= This feature existed back in 2012 5e7d6bba79
but got reverted with the incentive that there was a better approach.
After discussions, we agreed that it's a useful feature for apps
that have a really large set of routes.
Co-authored-by: Yehuda Katz <wycats@gmail.com>
This reverts commit 28e44f472d1cd6853726f85eeb7623e5901c4d37.
A limitation of Listen is that it currently only supports watching directories.
Therefore, watching `config/routes.rb` will end up watching the entire `config` directory
if we use the evented file watcher. This causes problems especially if symlinks are present
in the `config` directory.
* Refactor generator `route` action tests
Add `assert_routes` helper, which verifies that routes are always added
to the `Rails.application.routes.draw` block, are always indented, and
are always terminated with a newline. This "fixes" one test that was
not testing something it claimed to, and obsoletes another test.
Also, add a test case for indentation of multi-line routing code.
* Add :namespace option to generator `route` action
- The migrate task iterates and establish a connection over each db
resulting in the last one to be used by subsequent rake tasks.
We should reestablish a connection to the connection that was
established before the migrate tasks was run
- Fix#37578
We have these nice objects for collecting database configurations, so we
should use them everywhere instead of the hashes.
Also call `db_config.database` and `db_config.adapter` where necessary.
John Crepezzi <seejohnrun@github.com>
Make has_many inversing support available through an opt-in config
variable. This behaviour is likely to break existing applications, but
it is correct behaviour.
Services can be configured in `config/storage.yml` with a new key
`public: true | false` to indicate whether a service holds public
blobs or private blobs. Public services will always return a
permanent URL.
Deprecates `Blob#service_url` in favor of `Blob#url`.
We no longer link all js by default, so we should do this test with a
css instead (we don't care about that specifics of the dir just that its
in the manifest and in this dir).
Previously a path starting with ./ would be replaced to start with /.
IMO this didn't particularly make sense since / reads as though it's
from the root of the filesystem.
This commit removes that filter, preserves ./, and updates the silencer
not to remove lines starting with ./
It fixes the problem in propagating return_only_media_type_on_content_type
and fixes the corresponding test being ineffective.
The mentioned test addes the following line:
...config.action_dispatch.return_only_media_type_on_content_type = true
to the config and checks if it takes effect. However, in this scenario,
the value is already true before this line.
Moreover, the users are supposed to flip this from true to false in real
situations.
This commit flips the config in the test, making it to fail as
expected. The next commit will fix the failure.
In order for return_only_media_type_on_content_type to appropriately
take effect on ActionDispatch::Response, we want to know when
ActionDispatch::Response is loaded.
As load hooks for ActionDispatch would be too broad, the appropriate
registry is for ActionDispatch::Response itself.
Looking into other examples, a hook name is a full class name in
snake case with `_base` suffix omitted, if any. Therefore, in this case,
:action_dispatch_response seems appropriate.
We are seeing some test failures for this test in #37291. It looks like
what's going on is that Puma has changed the output for this command
between 4.1 and 4.2
Previously:
```
...
* Environment: development
* Listening on tcp://localhost:3000
...
```
Now:
```
...
* Environment: development
* Listening on tcp://127.0.0.1:3000
* Listening on tcp://[::1]:3000
...
```
So to get around this, instead of checking the binding address, just
check for the presence of 'Listening' generally like we do on server
start.
Co-authored-by: eileencodes <eileencodes@gmail.com>
Convert all uses of `db_config.configuration_hash[*]` to use methods
defined on an implementation of `DatabaseConfigurations::DatabaseConfig`.
Since we want to get away from accessing properties directly on the
underlying configuration hash, we'll move here to accessing those values
via the implementations on `DatabaseConfig` (or more specifically,
`HashConfig`).
There are still codepaths that are passing around `configuration_hash`,
and follow-on PRs will address those with the goal of using
configuration objects everywhere up until the point we pass a resolved
hash over to the underlying client.
Co-authored-by: eileencodes <eileencodes@gmail.com>
It is common to test Rails plugins with multiple versions of Rails.
When doing so, it's preferable that the dummy app be configured like an
actual Rails app would be, which includes loading version-appropriate
defaults. Additionally, using a dynamic version number eliminates
transient warnings that occur when testing newer versions of Rails with
older configuration defaults.
While generating an application with the `--skip-webpack-install` flag,
and then running `rails -h` on the generated application, I got the
crash listed below.
I was suprised that Rails would load the full application environment
just for the help command, so I located where the environment was being
loaded and stopped loading it.
It fixed the error and didn't break any tests, so it's probably not
necessary?
This is the backtrace for the error:
```
$ rails -h
The most common rails commands are:
generate Generate new code (short-cut alias: "g")
console Start the Rails console (short-cut alias: "c")
server Start the Rails server (short-cut alias: "s")
test Run tests except system tests (short-cut alias: "t")
test:system Run system tests
dbconsole Start a console for the database specified in config/database.yml
(short-cut alias: "db")
new Create a new Rails application. "rails new my_app" creates a
new application called MyApp in "./my_app"
All commands can be run with -h (or --help) for more information.
In addition to those commands, there are:
RAILS_ENV=development environment is not defined in config/webpacker.yml, falling back to production environment
Traceback (most recent call last):
74: from bin/rails:3:in `<main>'
73: from bin/rails:3:in `load'
72: from /home/deivid/Code/playground/testapp/bin/spring:15:in `<top (required)>'
71: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/site_ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
70: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/site_ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
69: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/binstub.rb:11:in `<top (required)>'
68: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/binstub.rb:11:in `load'
67: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/spring-2.1.0/bin/spring:49:in `<top (required)>'
66: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/client.rb:30:in `run'
65: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/client/command.rb:7:in `call'
64: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/client/rails.rb:28:in `call'
63: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/client/rails.rb:28:in `load'
62: from /home/deivid/Code/playground/testapp/bin/rails:9:in `<top (required)>'
61: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0/lib/active_support/dependencies.rb:325:in `require'
60: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0/lib/active_support/dependencies.rb:291:in `load_dependency'
59: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0/lib/active_support/dependencies.rb:325:in `block in require'
58: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
57: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:21:in `require_with_bootsnap_lfi'
56: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
55: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `block in require_with_bootsnap_lfi'
54: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require'
53: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/commands.rb:18:in `<main>'
52: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command.rb:46:in `invoke'
51: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command/base.rb:65:in `perform'
50: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
49: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
48: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
47: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/commands/help/help_command.rb:11:in `help'
46: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command.rb:86:in `print_commands'
45: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command.rb:96:in `commands'
44: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command.rb:96:in `flat_map'
43: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command.rb:96:in `each'
42: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/commands/rake/rake_command.rb:12:in `printing_commands'
41: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/commands/rake/rake_command.rb:42:in `formatted_rake_tasks'
40: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/commands/rake/rake_command.rb:33:in `rake_tasks'
39: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command/actions.rb:15:in `require_application_and_environment!'
38: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command/actions.rb:28:in `require_environment!'
37: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/application.rb:339:in `require_environment!'
36: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0/lib/active_support/dependencies.rb:325:in `require'
35: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0/lib/active_support/dependencies.rb:291:in `load_dependency'
34: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0/lib/active_support/dependencies.rb:325:in `block in require'
33: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.10/lib/zeitwerk/kernel.rb:23:in `require'
32: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
31: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:21:in `require_with_bootsnap_lfi'
30: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
29: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `block in require_with_bootsnap_lfi'
28: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require'
27: from /home/deivid/Code/playground/testapp/config/environment.rb:5:in `<main>'
26: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/application.rb:363:in `initialize!'
25: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/initializable.rb:60:in `run_initializers'
24: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:205:in `tsort_each'
23: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:226:in `tsort_each'
22: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:347:in `each_strongly_connected_component'
21: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:347:in `call'
20: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:347:in `each'
19: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:349:in `block in each_strongly_connected_component'
18: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:431:in `each_strongly_connected_component_from'
17: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:350:in `block (2 levels) in each_strongly_connected_component'
16: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:228:in `block in tsort_each'
15: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/initializable.rb:61:in `block in run_initializers'
14: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/initializable.rb:32:in `run'
13: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/initializable.rb:32:in `instance_exec'
12: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/railtie.rb:84:in `block in <class:Engine>'
11: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker.rb:27:in `bootstrap'
10: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/commands.rb:14:in `bootstrap'
9: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/manifest.rb:18:in `refresh'
8: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/manifest.rb:83:in `load'
7: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:47:in `public_manifest_path'
6: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:43:in `public_output_path'
5: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:39:in `public_path'
4: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:80:in `fetch'
3: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:84:in `data'
2: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:88:in `load'
1: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:88:in `read'
/home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:88:in `read': No such file or directory @ rb_sysopen - /home/deivid/Code/playground/testapp/config/webpacker.yml (Errno::ENOENT)
73: from bin/rails:3:in `<main>'
72: from bin/rails:3:in `load'
71: from /home/deivid/Code/playground/testapp/bin/spring:15:in `<top (required)>'
70: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/site_ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
69: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/site_ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
68: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/binstub.rb:11:in `<top (required)>'
67: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/binstub.rb:11:in `load'
66: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/spring-2.1.0/bin/spring:49:in `<top (required)>'
65: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/client.rb:30:in `run'
64: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/client/command.rb:7:in `call'
63: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/client/rails.rb:28:in `call'
62: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/spring-2.1.0/lib/spring/client/rails.rb:28:in `load'
61: from /home/deivid/Code/playground/testapp/bin/rails:9:in `<top (required)>'
60: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0/lib/active_support/dependencies.rb:325:in `require'
59: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0/lib/active_support/dependencies.rb:291:in `load_dependency'
58: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0/lib/active_support/dependencies.rb:325:in `block in require'
57: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
56: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:21:in `require_with_bootsnap_lfi'
55: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
54: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `block in require_with_bootsnap_lfi'
53: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require'
52: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/commands.rb:18:in `<main>'
51: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command.rb:46:in `invoke'
50: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command/base.rb:65:in `perform'
49: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
48: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
47: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
46: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/commands/help/help_command.rb:11:in `help'
45: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command.rb:86:in `print_commands'
44: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command.rb:96:in `commands'
43: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command.rb:96:in `flat_map'
42: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command.rb:96:in `each'
41: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/commands/rake/rake_command.rb:12:in `printing_commands'
40: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/commands/rake/rake_command.rb:42:in `formatted_rake_tasks'
39: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/commands/rake/rake_command.rb:33:in `rake_tasks'
38: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command/actions.rb:15:in `require_application_and_environment!'
37: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/command/actions.rb:28:in `require_environment!'
36: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/application.rb:339:in `require_environment!'
35: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0/lib/active_support/dependencies.rb:325:in `require'
34: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0/lib/active_support/dependencies.rb:291:in `load_dependency'
33: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/activesupport-6.0.0/lib/active_support/dependencies.rb:325:in `block in require'
32: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/zeitwerk-2.1.10/lib/zeitwerk/kernel.rb:23:in `require'
31: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
30: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:21:in `require_with_bootsnap_lfi'
29: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
28: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `block in require_with_bootsnap_lfi'
27: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require'
26: from /home/deivid/Code/playground/testapp/config/environment.rb:5:in `<main>'
25: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/application.rb:363:in `initialize!'
24: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/initializable.rb:60:in `run_initializers'
23: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:205:in `tsort_each'
22: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:226:in `tsort_each'
21: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:347:in `each_strongly_connected_component'
20: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:347:in `call'
19: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:347:in `each'
18: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:349:in `block in each_strongly_connected_component'
17: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:431:in `each_strongly_connected_component_from'
16: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:350:in `block (2 levels) in each_strongly_connected_component'
15: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/2.6.0/tsort.rb:228:in `block in tsort_each'
14: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/initializable.rb:61:in `block in run_initializers'
13: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/initializable.rb:32:in `run'
12: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/railties-6.0.0/lib/rails/initializable.rb:32:in `instance_exec'
11: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/railtie.rb:84:in `block in <class:Engine>'
10: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker.rb:27:in `bootstrap'
9: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/commands.rb:14:in `bootstrap'
8: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/manifest.rb:18:in `refresh'
7: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/manifest.rb:83:in `load'
6: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:47:in `public_manifest_path'
5: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:43:in `public_output_path'
4: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:39:in `public_path'
3: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:80:in `fetch'
2: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:84:in `data'
1: from /home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:87:in `load'
/home/deivid/.rbenv/versions/2.6.4/lib/ruby/gems/2.6.0/gems/webpacker-4.0.7/lib/webpacker/configuration.rb:91:in `rescue in load': Webpacker configuration file not found /home/deivid/Code/playground/testapp/config/webpacker.yml. Please run rails webpacker:install Error: No such file or directory @ rb_sysopen - /home/deivid/Code/playground/testapp/config/webpacker.yml (RuntimeError)
```
Eventually we'd like to get rid of this class altogether but for now
this PR reduces the surface area by removing methods from the class and
moving classes out into their own files.
* `adapter_method` was moved into database configurations
* `initialize_dup` was removed because it was only used in tests
* Resolver is now it's own class under connection adapters
* ConnectionUrlResolver, only used by the configurations, is in a class
under DatabaseConfigurations
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
Previously in some places we used symbol keys, and in some places we used
string keys. That made it pretty confusing to figure out in a particular
place what type of configuration object you were working with.
Now internally, all configuration hashes are keyed by symbols and
converted to such on the way in.
A few exceptions:
- `DatabaseConfigurations#to_h` still returns strings for backward compatibility
- Same for `legacy_hash`
- `default_hash` previously could return strings, but the associated
comment mentions it returns symbol-key `Hash` and now it always does
Because this is a change in behavior, a few method renames have happened:
- `DatabaseConfig#config` is now `DatabaseConfig#configuration_hash` and returns a symbol-key `Hash`
- `ConnectionSpecification#config` is now `ConnectionSpecification#underlying_configuration_hash` and returns the `Hash` of the underlying `DatabaseConfig`
- `DatabaseConfig#config` was added back, returns `String`-keys for backward compatibility, and is deprecated in favor of the new `configuration_hash`
Co-authored-by: eileencodes <eileencodes@gmail.com>
Currently, autoload paths pass to the watcher as directories. If using evented
watcher, this possibly pass as it is to `Listen`.
But autoload paths include files and `Listen` raise an error when was passed
file. So, it is necessary to classify files and directories correctly.
Fixes#37011.
Since 9c913116c634fe5fe2159a94b8f1a244801a4877, if you run `rackup`
in a machine that doesn't have that folder, the server will not start.
This doesn't happen on `rails s` because we create that folder when
starting the server on
8c8b02784a/railties/lib/rails/commands/server/server_command.rb (L70-L74).
We had two tests which assigned IO.console.winsize (to ensure output was
consistent), however it's possible for IO.console to be nil.
This commit makes these tests stub IO.console_size directly (the method
we actually call, we shouldn't have been relying on that calling
IO.console.winsize anyways) or passes the width when initializing the
class.
This allows tests to run without a TTY. This can be tested with ex.
ssh localhost "cd src/rails/actionpack && bundle exec rake"
or
(setsid bundle exec rake) </dev/null |& cat
Previously, we used the migration status to determine whether the test
database(s) needed to be reloaded from the schema. This worked in most
cases, but if a schema.rb was modified outside of migrations or if a
migration was rolled back, it would require a manual db:test:prepare.
This commit updates load_schema to record the SHA1 of the loaded schema
file inside of the ar_internal_metadata table. We can then use this SHA
to determine whether we should reload the schema.
This ensures that the test DB stays exactly in sync with the schema
file, including rollbacks which fixes a test marked TODO.
Didn't like the complicated stuff that happened on credentials:edit. It
would append to .gitattributes multiple times. Though I see why it was
written that way.
I'm cutting off for now, but since this new flow would require each developer
to run --enable perhaps this should really be:
1. Developer enrolls Rails app by running `credentials:diff --enable`
2. credentials:edit checks .gitattributes for `diff=rails_credentials` and
if the current file is covered by that.
3. If so, set up the "rails_credentials" driver automatically.
This hack prevails everywhere in the codebase by being copy & pasted, and it's actually not a negative thing but a necessary thing for framework implementors,
so it should better have a name and be a thing.
And with this commit, activesupport/test/abstract_unit.rb now doesn't silently autoload AS::TestCase,
so we're ready to establish clearner environment for running AS tests (probably in later commits)
The `rake db:seed` command was broken for the primary environment if the
application is using multiple databases. We never implemented `rake
db:seed` for other databases (coming soon), but that shouldn't break the
default case.
The reason this was broken was because `abort_if_pending_migrations`
would loop through the configs for all databases and check for
migrations but would leave the last established connection. So `db:seed`
was looking in the wrong database for the table to seed.
This PR doesn't fix the fact that `db:seed` doesn't work for multiple
databases but does fix the default case.
Fixes#36817
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
Applications are not supposed to use require_dependency in their own
code if running in zeitwerk mode, and require_dependency was initially
aliased to require with that use case in mind.
However, there are situations in which you cannot control the mode and
need to be compatible with both. There, you might need require_dependency
in case you are being executed in classic mode. Think about engines that
want to support both modes in their parent applications, for example.
Furthermore, Rails itself loads helpers using require_dependency.
Therefore, we need better compatibility.
- @sinsoku had the idea and started implementing it few months ago
but sadly didn't finish it.
This PR is taking over his work.
The credentials feature has changed a lot since @sinsoku opened hi
PR, it was easier to just restart from scratch instead of checking
out his branch.
Sinsoku will get all the credit he deserves for this idea :)
TL;DR on that that feature is to make the `git diff` or `git log`
of encrypted files to be readable.
The previous implementation was only setting up the git required
configuration for the first time Rails was bootstraped, so I decided
to instead provide the user a choice to opt-in for readable diff
credential whenever a user types the `bin/rails credentials:edit`
command.
The question won't be asked in the future the user has already
answered or if the user already opted in.
Co-authored-by: Takumi Shotoku <insoku.listy@gmail.com>
* read config/webpacker.yml to determine which path to exclude for zeitwerk:check
* fix test errors
* more changes to fix test errors
* refactor webpacker_path
[Andrew Kress + Rafael Mendonça França]
- I made a change in https://github.com/rails/rails/pull/36691 to
delegate route helper to a proxy class.
This didn't take into account that the `url_options` we redefine
in SystemTest would be ignored.
This PR fixes that by definin the url_options inside the proxy
A HTTP feature policy is Yet Another HTTP header for instructing the
browser about which features the application intends to make use of and
to lock down access to others. This is a new security mechanism that
ensures that should an application become compromised or a third party
attempts an unexpected action, the browser will override it and maintain
the intended UX.
WICG specification: https://wicg.github.io/feature-policy/
The end result is a HTTP header that looks like the following:
```
Feature-Policy: geolocation 'none'; autoplay https://example.com
```
This will prevent the browser from using geolocation and only allow
autoplay on `https://example.com`. Full feature list can be found over
in the WICG repository[1].
As of today Chrome and Safari have public support[2] for this
functionality with Firefox working on support[3] and Edge still pending
acceptance of the suggestion[4].
#### Examples
Using an initializer
```rb
# config/initializers/feature_policy.rb
Rails.application.config.feature_policy do |f|
f.geolocation :none
f.camera :none
f.payment "https://secure.example.com"
f.fullscreen :self
end
```
In a controller
```rb
class SampleController < ApplicationController
def index
feature_policy do |f|
f.geolocation "https://example.com"
end
end
end
```
Some of you might realise that the HTTP feature policy looks pretty
close to that of a Content Security Policy; and you're right. So much so
that I used the Content Security Policy DSL from #31162 as the starting
point for this change.
This change *doesn't* introduce support for defining a feature policy on
an iframe and this has been intentionally done to split the HTTP header
and the HTML element (`iframe`) support. If this is successful, I'll
look to add that on it's own.
Full documentation on HTTP feature policies can be found at
https://wicg.github.io/feature-policy/. Google have also published[5] a
great in-depth write up of this functionality.
[1]: https://github.com/WICG/feature-policy/blob/master/features.md
[2]: https://www.chromestatus.com/feature/5694225681219584
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801
[4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy
[5]: https://developers.google.com/web/updates/2018/06/feature-policy
Until Rails 5.2, generators can run same name multi times without destroying.
But Rails 6.0(with Zeitwerk) can't this. In Rails 6.0, an error occurs
due to class name collision check.
The check uses `const_defined?`, which assumes that the autoload object
is also defined.
https://ruby-doc.org/core-2.6.3/Module.html#method-i-const_defined-3F
It did not work until Rails 5.2, but Zeitwerk seems to be able to
correctly check this against the application's code.
However, this is a little inconvenient if want to run the generator
again like mistake an attribute name(need to run `destoy` before).
In order to solve this, this PR adds an option to skip the collision check.
With this option, you can overwrite files just as did until Rails 5.2.
For multiple databases we attempt to generate the tasks by reading the
database.yml before the Rails application is booted. This means that we
need to strip out ERB since it could be reading Rails configs.
In some cases like https://github.com/rails/rails/issues/36540 the ERB
is too complex and we can't overwrite with the DummyCompilier we used in
https://github.com/rails/rails/pull/35497. For the complex causes we
simply issue a warning that says we couldn't infer the database tasks
from the database.yml.
While working on this I decided to update the code to only load the
database.yml once initially so that we avoid having to issue the same
warning multiple times. Note that this had no performance impact in my
testing and is merely for not having to save the error off somewhere.
Also this feels cleaner.
Note that this will not break running tasks that exist, it will just
mean that tasks for multi-db like `db:create:other_db` will not be
generated. If the database.yml is actually unreadable it will blow up
during normal rake task calls.
Fixes#36540
I changed to set CSP nonce to `style-src` directive in #32932.
But this causes an issue when `unsafe-inline` is specified to `style-src`
(If a nonce is present, a nonce takes precedence over `unsafe-inline`).
So, I fixed to nonce directives configurable. By configure this, users
can make CSP as before.
Fixes#35137.
I changed return value of `ActionDispatch::Response#content_type` in #36034.
But this change seems to an obstacle to upgrading. https://github.com/rails/rails/pull/36034#issuecomment-498795893
Therefore, I restored the behavior of `ActionDispatch::Response#content_type`
to 5.2 and deprecated old behavior. Also, made it possible to control the
behavior with the config.
Previously it was only possible to specify the location of the pidfile
for the 'rails server' command with the '-P' flag. This adds support for
specifying the pidfile using a PIDFILE env var, which can still be
overridden by the '-P' flag and with the default pidfile path unchanged.
The motivation for this feature comes from using Docker to run multiple
instances of the same rails app. When developing a rails app with
Docker, it's common to bind-mount the rails root directory in the
running container, so that changes to files are shared between the
container and the host. However, this doesn't work so well with the
pidfile and it's necessary to (remember to) add a '-P' flag to the
'rails server' command line; being able to specify this flag using an
env var would make developing with Rails+Docker a bit simpler.
This PR moves the `schema_migration` to `migration_context` so that we
can access the `schema_migration` per connection.
This does not change behavior of the SchemaMigration if you are using
one database. This also does not change behavior of any public APIs.
`Migrator` is private as is `MigrationContext` so we can change these as
needed.
We now need to pass a `schema_migration` to `Migrator` so that we can
run migrations on the right connection outside the context of a rake
task.
The bugs this fixes were discovered while debugging the issues around
the SchemaCache on initialization with multiple database. It was clear
that `get_all_versions` wouldn't work without these changes outside the
context of a rake task (because in the rake task we establish a
connection and change AR::Base.connection to the db we're running on).
Because the `SchemaCache` relies on the `SchemaMigration` information we
need to make sure we store it per-connection rather than on
ActiveRecord::Base.
[Eileen M. Uchitelle & Aaron Patterson]
When someone has a multi-db application their `ApplicationRecord` will
look like:
```ruby
class ApplicationRecord < ActiveRecord::Base
self.abstract_class = true
connects_to database: { writing: :primary, reading: :replica }
end
```
This will cause us to open 2 connections to ActiveRecord::Base's
database when we actually only want 1. This is because Rails sees
`ApplicationRecord` and thinks it's a new connection, not the existing
`ActiveRecord::Base` connection because the
`connection_specification_name` is different.
This PR changes `ApplicationRecord` classes to consider themselves the
same as the "primary" connection.
Fixes#36382
`spring-watcher-listen` watch application root by default.
c4bfe15805/lib/spring/watcher/listen.rb (L58)
This is necessary to watch the file (e.g. `.ruby-version`) in the
application root.
By this `node_modules` also be watched, and it is a possibility to be
shown a warning by `listen`.
Related to #32700, #34912, https://github.com/rails/webpacker/issues/1990.
`listen` watches directory recursive by default, and it cannot avoid it.
https://github.com/guard/listen/issues/111
So If this warning happens, the only workaround the user can do is remove
the gem.
The issue is likely to occur more frequently in Rails 6 because
`rails new` runs `webpacker:install` by default. Because of such a
state, I think that we should not recommend to use
`spring-watcher-listen`.
Spring has polling watcher, restart process works without this
`spring-watcher-listen`.
Because of polling base, CPU load may be higher than listen base. Still
I think that it is better than the warning comes out.
Previously, if a test worker exited early, the in-flight test it was
supposed to run wasn't reported as a failure.
If all workers exited immediately, this would be reported as ex.
Finished in 1.708349s, 39.2192 runs/s, 79.0237 assertions/s.
67 runs, 135 assertions, 0 failures, 0 errors, 2 skips
This commit validates that all workers finish running tests by ensuring
that the queue is empty after they exit. This works because we signal
the workers to exit by pushing nil onto the queue, so that there should
be a number of items left in the queue matching potentially missed
tests.
*sigh* this seems like the never ending bug. I don't love or even like
this fix but it does _work_.
Rafael suggested using `dummy_key: dummy_value` but unfortunately
that doesn't work. So we're left with checking whethere there might be
ternary type things in the content and then assuming that we want to
replace the line with a key value pair.
Technically fixes https://github.com/rails/rails/issues/36088
The virtual attributes(`attachment` and `rich_text`) can't set value
with `fill_in`. So avoid using it. Once #35885 is merged, will be
modified to use it.
Also, add checking attachment attached or not for avoiding
`DelegationError` when attachment didn't attach.
As suggested in https://github.com/rails/rails/issues/35602#issuecomment-485833483, because we don't provide view caching and doesn't include `ActionController::Caching` for api apps, we should also avoid generating
```ruby
config.action_controller.perform_caching = true
```
for those api apps. So it won't confuse people.
**But because `perform_caching` will be `true` if not set, the behavior of the app would still be the same without these configs.**
This commit more or less undoes 9b5401f, restores autoloaded? not to
touch the descendants tracker, and autoloaded_constants because it is
documented in the guide.
Previously we were calling the `take_failed_screenshot` method in an
`after_teardown` hook. However, this means that other teardown hooks
have to be executed before we take the screenshot. Since there can be
dynamic updates to the page after the assertion fails and before we
take a screenshot, it seems desirable to minimize that gap as much as
possible. Taking the screenshot in a `before_teardown` rather than an
`after_teardown` helps with that, and has a side benefit of allowing
us to remove the nested `ensure` commented on here:
https://github.com/rails/rails/pull/34411#discussion_r232819478
With 8b4d344815655027d9f7584c0a59271dce8f1d5a, `test_required_polymorphic_belongs_to_generates_correct_model`
and `test_required_and_polymorphic_are_order_independent` are completely
same. Also, remove `required` from test name because that not passed to
generator.
This change adds the ability to run up/down for a database in a multi-db
environment.
If you have an app with a primary and animals database the following
tasks will be generated:
```
VERSION=123 rake db:migrate:up:primary
VERSION=123 rake db:migrate:up:primary
VERSION=123 rake db:migrate:down:primary
VERSION=123 rake db:migrate:up:animals
```
I didn't generate descriptions with them since we don't generate a
description for a single database application.
In addition to this change I've made it so if your application has
multiple databases Rails will raise if you try to run `up` or `down`
without a namespace. This is because we don't know which DB you want to
run `up` or `down` against unless the app tells us, so it's safer to
just block it and recommend using namespaced versions of up/down
respectively.
The output for the raise looks like:
```
You're using a multiple database application. To use `db:migrate:down`
you must run the namespaced task with a VERSION. Available tasks are
db:migrate:down:primary and db:migrate:down:animals.
```
- Also deprecate passing {required} to the model generator.
- Also made sure the global config `belongs_to_required_by_default` is
applied correctly to the model generator for `null: false` option.
Currently ActionController::API doesn't include Caching module, so it
can't perform caching. And even if users include it later manually, it
won't inherit application's default cache store for action_controllers.
So the only way to solve this issue is to include Caching module in
ActionController::API, too.
This closes#35602
`bin/setup` and `bin/update` are currently almost the same file. The
only thing that keeps them apart is that one is running `bin/rails
db:setup` and the other `bin/rails db:migrate`.
I'm suggesting here that they should be a unique script, which needs to
be idempotent.
- New to a project, need to get started? `bin/setup`
- Need to install new dependencies that were added recently? `bin/setup`.
Before deprecating `bin/update`, I'm suggesting we just have it call
`bin/setup`.
This way, we only need to filter the backtrace up to the first non-noise
stack frame.
This also updates noise to be able to deal with being passed a lazy
enum. We don't need this anywhere, but it seemed better for this to be
consistent.
`belongs_to` association have `required: true` by default
https://github.com/rails/rails/pull/18937 onwards so we don't need it
in the generator template.
We still need the code for required in the command line generator as
it adds `null: false` in the migration.
In `app:update`, it is decided whether to skip depending on whether
`Spring` is defined or not.
However, `spring` is not currently specified in Gemfile. As a result,
`app:update` determines that `Spring` is not used, and diff appears in
the result file.
If there is a difference, the console for processing the difference is
output and the test stops. To avoid this, do not include `Spring` in app.
This is a bit strange approach, so I will revisit this later.
