The flexibility provided by `config.x` supports arbitrarily defining new
configuration objects on-the-fly. Each new intermediate configuration
object is constructed during chaining from its ancestor through a method
invocation made without arguments.
Conversely, writing to leaf configuration values occurs when the invoked
method's name ends with `=`, and the new configuration value is assigned
to whatever that method's arguments are.
There are no cases when reading from a `config.x` value or building the
intermediate values involves arguments.
Prior to this commit, a read invoked with a method arguments would
ignore those arguments. While this is robust and error-free, it's
possible to obscure misuse.
For example, consider a line like:
```ruby
config.x.my_config.enabled = true
config.x.my_config.enabled #=> true
```
Now consider that first line with a typo that omits the `=`:
```ruby
config.x.my_config.enabled true
config.x.my_config.enabled #=> nil
```
This commit aims to provide more direct feedback for scenarios like the
one above. There aren't legitimate use cases for invoking `#enabled`
with arguments, so raise a `ArgumentError` when encountering a read with
arguments.
* Apply autocorrection by RuboCop to files generated by `bin/rails generate`
## Motivation / Background
RuboCop has now been included by default (#50456).
By adding the following tip to the default configuration, user can apply RuboCop's autocorrection to
code generated by `bin/rails generate` (e.g., migration file):
https://github.com/rubocop/rubocop-rails#rails-configuration-tip
This means that the generated files will be formatted according to user's .rubocop.yml custom configuration.
## Detail
Since `bin/rails generate` and `bin/rubocop` are used only in the development environment,
the target files are limited to only `config/environments/development.rb`.
## Additional information
This feature was introduced in Rails 6.1 by https://github.com/rails/rails/pull/38870.
Until now, Rails only droped compatibility with older
rubies on new majors, but I propose to change this policy
because it causes us to either keep compatibility with long
EOLed rubies or to bump the Rails major more often, and to
drop multiple Ruby versions at once when we bump the major.
In my opinion it's a bad alignments of incentives. And we'd
be much better to just drop support in new minors whenever they
go EOL (so 3 years).
Also Ruby being an upstream dependency, it's not even
a semver violation AFAICT.
Since Rails 7.2 isn't planned before a few months, we
can already drop Ruby 3.0 as it will be EOL in March.
* Add rubocop to new rails app generator
This setups a basic rubocop config for new rails apps using the `rubocop-rails-omakase` gem:
https://github.com/rails/rubocop-rails-omakase
It can be skipped with the `--skip-rubocop` flag.
Until now, Rails only droped compatibility with older
rubies on new majors, but I propose to change this policy
because it causes us to either keep compatibility with long
EOLed rubies or to bump the Rails major more often, and to
drop multiple Ruby versions at once when we bump the major.
In my opinion it's a bad alignments of incentives. And we'd
be much better to just drop support in new minors whenever they
go EOL (so 3 years).
Also Ruby being an upstream dependency, it's not even
a semver violation AFAICT.
Since Rails 7.2 isn't planned before a few months, we
can already drop Ruby 3.0 as it will be EOL in March.
There are valid use cases for running SQLite in production, however it must be done
with care, so instead of a warning most users won't see anyway, it's preferable to
leave the configuration commented out to force them to think about having the database
on a persistent volume etc.
Co-Authored-By: Jacopo Beschi <beschi.jacopo@gmail.com>
This commit addresses the CI failure against Ruby master branch.
https://buildkite.com/rails/rails/builds/102575#018c4147-8760-48ac-812c-4e63fbe242fa
This failure reproduces since this commit:
d411d8f5fe
* Steps to reproduce
Install `ruby 3.3.0dev`
```ruby
git clone https://github.com/rails/rails
cd rails/railties
rm ../Gemfile.lock
bundle
bin/test test/application/bin_setup_test.rb -n test_bin_setup_output
```
* Without this commit
```ruby
$ ruby -v
ruby 3.3.0dev (2023-12-16T21:45:33Z master d7d10f3ee8) [x86_64-linux]
$ rm ../Gemfile.lock ; bundle ; bin/test test/application/bin_setup_test.rb -n test_bin_setup_output
... snip ...
F
Failure:
ApplicationTests::BinSetupTest#test_bin_setup_output [/home/yahonda/src/github.com/rails/rails/railties/test/application/bin_setup_test.rb:51]:
--- expected
+++ actual
@@ -2,10 +2,12 @@
The Gemfile's dependencies are satisfied
== Preparing database ==
+/home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/zeitwerk-2.6.12/lib/zeitwerk/kernel.rb:38: warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec.
Created database 'app_development'
Created database 'app_test'
== Removing old logs and tempfiles ==
+/home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/zeitwerk-2.6.12/lib/zeitwerk/kernel.rb:38: warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec.
== Restarting application server ==
"
bin/test test/application/bin_setup_test.rb:30
Finished in 12.553516s, 0.0797 runs/s, 0.0797 assertions/s.
1 runs, 1 assertions, 1 failures, 0 errors, 0 skips
$
```
To assert the expected number of queries are made, Rails internally uses
`assert_queries` and `assert_no_queries`. These assertions can be
useful in applications as well.
By extracting these assertions to a module, the assertions can be
included where required.
These assertions are added to `ActiveSupport::TestCase` when
ActiveRecord is defined.
ActiveStorage, ActionView and ActionText are using this module now as
well, instead of duplicating the implementation.
The internal ActiveRecord::TestCase, used for testing ActiveRecord,
implements these assertions as well. However, these are slighlty more
advanced/complex and use the SQLCounter class. To keep things simple,
for now this implementation isn't used.
When set, validates that the timestamp prefix for a migration is in the form YYYYMMDDHHMMSS.
This is designed to prevent migration timestamps from being modified by hand.
It is turned off by default.
