* Action Text JS should be available via the asset pipeline too
* Main was a module anyway, no need to reference that twice
* Fix rollup references
* Precompile action text JS for asset pipeline
* No JavaScript dependencies needed with the asset pipeline
* Stub Webpacker::Engine to trigger webpack path for testing
* Extract asset paths
* Exercise asset pipeline path
* Terser doesn't do anything useful on this small package
* Make trix directly available to the asset pipeline
* Indirect doesn't carry its worth
* Reminder for development about keeping things in sync for the asset pipeline
* Ensure this isn't turned into undefined while mirroring
* Mirror Trix CSS for asset pipeline
* Add the needed JS include tag automatically under the asset pipeline
* Please RuboCop
* Keep the peer dependency
Even though we also need it explicitly as a dev dependency in order to generate the mirror output for trix.
* Fix test
* Add CHANGELOG entry
Setting `remove_deprecated_time_with_zone_name` didn't work because
the value is checked in a framework initialiser, which runs before application initialiser.
This PR moves the setting inside the `config.after_initialize` block.
I've also added 2 tests for this behaviour.
Fixes#42820
When running `bin/rails -h` the following messages is shown:
> All commands can be run with -h (or --help) for more information.
This doesn't apply to the commands that are Rake tasks like db:migrate.
If you run `bin/rails db:migrate -h` you'll get the Rake help, which
can be confusing...
Instead, if we replace the `-h` argument with `--describe db:migrate`
Rails outputs the Rake task descriptions, which are a lot more helpful:
rails db:migrate
Migrate the database (options: VERSION=x, VERBOSE=false, SCOPE=blog).
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
Dumping the schema is on by default for all databases in an application. To turn it off for a
specific database use the `schema_dump` option:
```yaml
# config/database.yml
production:
schema_dump: false
```
Co-authored-by: Luis Vasconcellos <vasconcelloslf@gmail.com>
Since 2801786e1a51b7cf7d7c3fd72b5fc9974f83f435 these are eager
autoloaded, so there's no reason to require them explicitly.
Both classes have configuration applied via load hooks, so requiring
them too early could cause load order issues. In particular, an
application that referenced any of the middleware that required these
classes would be prevented from configuring them afterwards.
This lets us remove the reference to DebugExceptions from the Action
Dispatch railtie, which was causing load order issues since it depends
on ActionDispatch::Request.
This adds an additional method to configure the parallelization
threshold. Before this, the only way of configuring the threshold was
via an option:
```
config.active_support.test_parallelization_minimum_number_of_tests
```
- Related to https://github.com/rails/rails/pull/42761
- Used `parallelized?` method instead of calling a method `should_parallelize?` to figure out if parallezation is enabled.
- Fixed semantics of the test name corresponding to the change
- Updated test name as per the code review suggestion.
Parallelizing tests has a cost in terms of database setup and fixture
loading. This change makes Rails disable parallelization when the number
of tests is below a configurable threshold.
When running tests in parallel each process gets its own database
instance. On each execution, each process will update each database
schema (if needed) and load all the fixtures. This can be very expensive
for non trivial datasets.
As an example, for HEY, when running a single file with 18 tests,
running tests in parallel in my box adds an overhead of 13 seconds
versus not parallelizing them. Of course parallelizing is totally worthy
when there are many tests to run, but not when running just a few tests.
The threshold is configurable via
config.active_support.test_parallelization_minimum_number_of_tests,
which is 30 50 by default.
This also adds some tracing to know how tests are being executed:
When in parallel:
```
Running 2829 tests in parallel in 8 processes
```
When not in parallel:
```
Running 15 tests in a single process (parallelization threshold is 30)
```
Ref: https://github.com/rails/rails/pull/42355
The justification for `partial_inserts` back in 2012
(144e8691cbfb8bba77f18cfe68d5e7fd48887f5e) was:
> This is more efficient, and also means that it will be safe to remove
> database columns without getting subsequent errors in running app processes
> (so long as the code in those processes doesn't contain any references to the
> removed column).
But since then `ignored_columns` is a much more reliable way to safely remove a
column, and I doubt the reduced query size really help much.
Additionally, `partial_inserts` prevent removing the default value of a column
in a safe way.
This reverts commit 1cdee90d385399083596c22343cc46f51283aca3, reversing
changes made to c3a1bfe187d594ed2c2348cc0ae6c5c894368b8e.
We are reverting this because it caused a change in behavior and we need
to discuss how to address that behavior change and find a work around
that doesn't break existing applications.
In Rails 7 zeitwerk_enabled? returns true unconditionally. It exists to let 3rd
party code supporting multiple Rails versions check, but we no longer need to use
it internally.
When writing fixtures, it's currently possible to define associations that don't exist, even if a foreign key exists. For example:
```yml
george:
name: "Curious George"
pirate: redbeard
blackbeard:
name: "Blackbeard"
```
When the fixtures are created, `parrots(:george).pirate` will be nil, but it's not immediately clear why. This can make it hard to debug tests and can give false confidence in passing ones.
This can happen because Rails [disables referential integrity](f263530bf7/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb (L407)) when inserting fixtures. This makes the fixtures algorithm much simpler - it can just create the fixtures in alphabetical order and assume that the other side of a foreign key constraint will *eventually* be added.
Ideally we would check foreign keys once all fixtures have been loaded, so that we can be sure that the foreign key constraints were met. This PR introduces that. To enable it:
```ruby
config.active_record.verify_foreign_keys_for_fixtures = true
```
I'm proposing we enable this in 7.0 for new apps and have added it to new framework defaults. When run against our app, it found 3 fixture files with unmet FK constraints - turns out all those fixtures weren't being used and were safe to delete.
`railties/lib/rails/application/configuration.rb` contains defaults that
haven't been added to the `new_framework_defaults_7_0.rb.tt`.
This adds these defaults to ease migration.
Framework defaults cause confusion for contributors when adding new
defaults. Should the defaults be defined in:
`railties/lib/rails/application/configuration.rb` and/or
`config/initializers/new_framework_defaults_7_0.rb.tt`
And should these define the new or old defaults?
Hopefully this clarifies it by making it clear the
new framework defaults are commented out.
By mentioning `config.load_defaults` it hopefully clarifies that these
defaults should be similar to the onces defined by `load_defaults`.
Also reword "flip" to "uncomment" to make it clear you should uncomment
the config instead of setting `true` to `false`.
Fix a bug introduced by
3fe0ab52df
that raised an undefined method when trying to deep merge an array with
an empty config hash
It also adds a test to clarify config_for behaviour with root arrays: when there's
an env array and a shared array, it should only returns the env key (and not a concatenation)
Closes#42698
When passing an invalid index type to a generator, the index is silently
ignored. For example when misspelling the index:
bin/rails g model post title:string:indxe
Instead of silently ignoring the invalid index, the generator should
raise an error.
This continues the work in d163fcd6208c9b0507746888c7fb4a6f934303ce
where we started raising errors if the attribute types are invalid.
All new 7.0 framework defaults don't have an extra linebreak between the
explanation and the actual config.
For consistency we should remove it for `hash_digest_class` as well.
As of Ruby 2.7 DidYouMean is included as a default gem, so there is no
need to check if DidYouMean is defined in the test suite. We still need
to check if the DidYouMean modules are defined in the actual code, as
someone might run Rails with DidYouMean disabled by using the
`--disable-did_you_mean` flag. This is ussually done for performance
reasons.
This commit also includes some of the changes made by Yuki in:
https://github.com/rails/rails/pull/39555
These changes include replacing Jaro with the more accurate
SpellChecker, and using DidYouMean::Correctable for simplere
corrections.
The DidYouMean::SpellChecker does have a treshold for corrections.
If there is not enough similarity it might not return a suggestion.
To stop the tests from failing some test data had to be changed.
For example, `non_existent` does not meet the treshold for `hello`, but
`ello` does:
DidYouMean::SpellChecker.new(dictionary: %w[hello]).correct('non_existent')
=> []
DidYouMean::SpellChecker.new(dictionary: %w[hello]).correct('ello')
=> ["hello"]
The treshold makes sense for spelling errors. But maybe we should add a
different SpellChecker that helps to get a suggestion even if there is
little overlap. For example for when a model only has 2 attributes
(title and body), it's helpful to get a suggestion for `name`
Co-Authored-By: Yuki Nishijima <yk.nishijima@gmail.com>
This is imperfect in situations when a separation
between regular files (such as uploads) and emails
is necessary (for the purposes of regulatory compliance,
proper compartmentalization, etc.)
Solution: allow configuring ActionMailbox's storage service
