Since 6983a89c726243fb38fe28cff49cba3a5f63ba6f `require_dependency` is
obsolete since Rails stopped supporting classic mode.
It is only used by engines that need to support classic mode as well.
We can safely remove internal usage of `require_dependency`.
It was only used in the ActionMailer::Preview which is using just
`require` anyway.
Since this method has been documented in the guides for ages, it's probably safe.
https://guides.rubyonrails.org/testing.html#revenge-of-the-fixtures
TODO: I don't like how these methods are documented on
ActionMailer::TestCase::Behavior, even though the API is meant to be
exposed through ActionMailer::TestCase
Also add some additional words to make it clear that the modules also
implement handling the exceptions configured with rescue_from, because
it was not immediately clear that happened without reading the code.
In #45752, a `:params` kwarg was added to `assert_enqueued_email_with`
so that mailer params and args could be specified simultaneously.
However, for backward compatibility, the old behavior of treating an
`:args` Hash as params was preserved. The result is that if both
`:params` and `:args` are specified and `:args` is a Hash, `:params` is
ignored.
This commit deprecates specifying params via `:args` (i.e. passing a
Hash to `:args`).
After the deprecated behavior is removed, it will be possible to pass
a Hash to `:args`, and the Hash will be treated as named args instead.
Support args/params proc matchers in `assert_enqueued_email_with` to
make it behave more like `assert_enqueued_with`.
Fix#46621.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
The `Type` class was introduced in https://github.com/rails/rails/pull/23085
for the sole purpose of breaking the dependency of Action View on Action Dispatch.
Unless you are somehow running Action View standalone, this is actually
never used.
So instead of delegating, we can use constant swapping, this saves us
a useless layer.
Ultimately we could consider moving `Mime::Types` into Active Support
but it requires some more thoughts.
Currently when opening the main framework pages there is no introduction
to the framework. Instead we only see a whole lot of modules and the
`gem_version` and `version` methods.
By including the READMEs using the `:include:` directive each frameworks
has a nice introduction.
For markdown READMEs we need to add the :markup: directive.
[ci-skip]
Co-authored-by: zzak <zzakscott@gmail.com>
* Remove Copyright years
* Basecamp is now 37signals... again
Co-authored-by: David Heinemeier Hansson <dhh@hey.com>
---------
Co-authored-by: David Heinemeier Hansson <dhh@hey.com>
The `deliver_later_queue_name` is already configurable on ActionMailer::Base,
however the value is inherited by all subclasses. Use a class-inheritable
attribute instead, so that subclasses can override.
Refs:
- https://github.com/rails/rails/pull/18587#issuecomment-324975192
Prior to this change, access to `params` on `ActionMailer::Base`
instances prior to being decorated by `ActionMailer::Parameterized.with`
calls results in a `NoMethodError`:
```
Error:
ParameterizedTest#test_degrade_gracefully_when_.with_is_not_called:
NoMethodError: undefined method `[]' for nil:NilClass
before_action { @inviter, @invitee = params[:inviter], params[:invitee] }
^^^^^^^^^^
```
This change modifies the `attr_accessor :params` to be an `attr_writer`
paired with a `params` method that assigns `@params` to an empty `Hash`
whenever it's accessed without being otherwise initialized.
This pattern is pretty common:
```ruby
assert_emails 1 do
post invite_user_path # ...
end
email = ActionMailer::Base.deliveries.last
assert_equal "You were invited!", email.subject
```
We can make it a bit nicer, by returning the email object from `assert_emails`. This is similar to how `assert_raises` returns the error so you can do additional checks on it. With this PR:
```ruby
email = assert_emails 1 do
post invite_user_path # ...
end
assert_equal "You were invited!", email.subject
```
If a single email is sent, a single `Mail::Message` is returned. If multiple emails were sent, an array is returned.
```ruby
emails = assert_emails 2 do
post invite_user_path # ...
end
emails.each do |email|
assert_equal "You were invited!", email.subject
end
```
The Mail gem changed format of the delivery method arguments for
sendmail from a string to an array of strings in this commit
7e1196bd29
As the settings are now a sendmail delivery method produces the
following error:
```
.../mail-2.8.0/lib/mail/network/delivery_methods/sendmail.rb:53:in `initialize': :arguments expected to be an Array of individual string args (ArgumentError)
```
This also updates the mail dependency since the new default won't work
with the older versions.
Since engine initializers run later in the process, we need to run this
initializer earlier than the default.
This ensures they're all registered before the environments are loaded.
This commit adds `ActionMailer.deprecator` and replaces all usages of
`ActiveSupport::Deprecation.warn` in `actionmailer/lib` with
`ActionMailer.deprecator`.
Additionally, this commit adds `ActionMailer.deprecator` to
`Rails.application.deprecators` so that it can be configured via
settings such as `config.active_support.report_deprecations`.
This commit adds `ActionDispatch.deprecator` and replaces all usages of
`ActiveSupport::Deprecation.warn` in `actionpack/lib/action_dispatch`
with `ActionDispatch.deprecator`.
Additionally, this commit adds `ActionDispatch.deprecator` to
`Rails.application.deprecators` so that it can be configured via
settings such as `config.active_support.report_deprecations`.
We recently let a few very easy to avoid warnings get merged.
The root cause is that locally the test suite doesn't run in
verbose mode unless you explictly pass `-w`.
On CI warnings are enabled, but there is no reason to look at the
build output unless something is failing. And even if one wanted
to do that, that would be particularly work intensive since warnings
may be specific to a Ruby version etc.
Because of this I believe we should:
- Always run the test suite with warnings enabled.
- Raise an error if a warning is unexpected.
We've been using this pattern for a long time at Shopify both in private
and public repositories.
Rubinius has not been maintained since May 2020 and based on the
discussion at https://github.com/rails/rails/pull/44984 ,
I think we can remove Rubinius specific code from Rails.
The various LogSubscriber subclasses tend to subscribe to events
but then end up doing nothing if the log level is high enough.
But even if we end up not logging, we have to go through the
entire notification path, record timing etc.
By allowing subscribers to dynamically bail out early, we can
save a lot of work if all subscribers are silenced.
