`codespell` works with a small custom dictionary and seems to find perhaps more spelling mistakes than `misspell` which really only fixes commonly misspelled English words.
Not all spell checkers can check all file types and most spell checkers can't find all the errors.
https://github.com/codespell-project/codespellhttps://pypi.org/project/codespell/
The default is set to 5 and only applied for new applications or
applications that opt-in for this new default.
Closes#42089.
[André Luis Leal Cardoso Junior + Rafael Mendonça França]
Running tests in parallel with processes wasn't failing fast when the
option was enabled. The problem was that even when the reporter raised
the `Interrupt` exception, the queue was not emptied, so workers keep
processing jobs as if nothing happened.
This patch basically intercepts the `Interrupt` exception that may
come from the reporter, and tells the server to clear the jobs queue,
so that it can continue the shutdown process as usual. The exception
must then continue its journey so that the backtrace is displayed.
Previous discussion: #38412, #38325, 37423e4, 24f9c03
- Rack::Runtime is replaced by FakeRuntime, which is a dummy middleware
that just passes requests on and cannot be used in middleware operations
- Using Rack::Runtime in middleware operations (relative inserts, moves,
etc.) throws a deprecation warning and uses FakeRuntime instead
- if an application adds Rack::Runtime explicitly (use, unshift, etc.),
then the deprecation warning does not happen and FakeRuntime is
ignored
- docs are updated to no longer reference Rack::Runtime
Follow-up to #38495.
Similar to #40994, but for all Rails commands. Programmatic and CLI
invocations of Rails commands will still behave identically, and `ARGV`
will still be isolated between invocations.
Reverts #40994.
Reverts a change from
2327ebfdc6
which can overwrite `test_order` that may have been manually set in
config. This can cause a situation where the user is depending on a
particular `test_order` but is unknowingly forced into another.
Setting up the parallel workers could be an overhead when running
individual files.
This patch disables that process in case the number of files to run
is less than one.
Results running a sample file:
Before:
```
actionpack $ bin/test test/controller/parameters/accessors_test.rb
Run options: --seed 48261
........................................................................
Finished in 0.211923s, 339.7460 runs/s, 552.0873 assertions/s.
72 runs, 117 assertions, 0 failures, 0 errors, 0 skips
```
After
```
actionpack $ bin/test test/controller/parameters/accessors_test.rb
Run options: --seed 5461
........................................................................
Finished in 0.008411s, 8560.2189 runs/s, 13910.3557 assertions/s.
72 runs, 117 assertions, 0 failures, 0 errors, 0 skips
```
This starts a series of patches in which we drop classic mode. The final
result no longer has a const_missing callback, there is no hook/unhook,
and so on.
So, in this patch we remove the ability of configuring classic, but some
of the code that remains will be further refactored.
The helpers of Action Text are added to a couple of non-reloadable
base classes:
initializer "action_text.helper" do
%i[action_controller_base action_mailer].each do |abstract_controller|
ActiveSupport.on_load(abstract_controller) do
helper ActionText::Engine.helpers
end
end
end
Therefore, it does not make sense that they are reloadable themselves.
For the same price, we can also make the models non-reloadable, thus
saving parent applications from the unnecessary work of reloading this
engine.
We did this for turbo-rails as well.
* Guard against using VERSION with db:rollback
I recently ran a migration that I needed to rollback, and admittedly, I often forget the proper incantation for this 😅
so the first thing I tried was to run `bin/rake db:rollback VERSION=123454679`. I had hoped that this reverted my
migration back and at first glance I thought it worked. However on closer inspection I realized that it was a different
migration, which initially confused me.
So I looked over the docs and saw that I was using the rake task incorrectly, and promptly corrected my mistake.
Proposal
Looking at the how the `:down` task is defined we see
8dc7439058/activerecord/lib/active_record/railties/databases.rake (L206-L211)
This got me thinking that maybe it would be helpful to have the opposite of this guard defined in `rollback` so that if
`VERSION` is passed it will raise an exception instead of just negecting the extra argument. This could help the user
realize that something went wrong instead of just seeing output and assuming that the rollback happened.
Change
We now raise an execption if `VERSION` is passed when attempting to rollback a migration
* update test name and fix failing test
* remove byebug
[Nick Borromeo + Kate Travers + Rafael Mendonça França]
Followup on https://github.com/rails/rails/pull/41258#discussion_r570441592
This makes sure that newly generated applications get their
`ApplicationRecord` set to `primary_abstract_class`. Existing applications
can opt-in to this if they're using multiple databases or have changed
their `ApplicationRecord` to a class with a different name.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
