* Remove pidfile in production
* Update changelog
* Update activestorage/test/dummy/config/puma.rb
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
* Update template and other dummy files
---------
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
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.
* 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.
The db:system:change command was [updated][1] to include support for
changing the database packages installed in the Dockerfile. However, it
never checks that the Dockerfile exists before trying to perform a
substitution and will raise an error when its missing:
```
/home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/actions/file_manipulation.rb:272:in `binread': No such file or directory @ rb_sysopen - /home/hartley/test/dev_minimal/Dockerfile (Errno::ENOENT)
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/actions/file_manipulation.rb:272:in `gsub_file'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/generators/rails/db/system/change/change_generator.rb:47:in `edit_dockerfile'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/command.rb:28:in `run'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:127:in `invoke_command'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:134:in `block in invoke_all'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:134:in `each'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:134:in `map'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:134:in `invoke_all'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/group.rb:232:in `dispatch'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/base.rb:584:in `start'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/commands/db/system/change/change_command.rb:20:in `perform'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/command.rb:28:in `run'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:127:in `invoke_command'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/command/base.rb:178:in `invoke_command'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor.rb:527:in `dispatch'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/command/base.rb:73:in `perform'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/command.rb:71:in `block in invoke'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/command.rb:149:in `with_argv'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/command.rb:69:in `invoke'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/commands.rb:18:in `<top (required)>'
from bin/rails:4:in `require'
from bin/rails:4:in `<main>'
```
This commit fixes the issue by checking first whether the Dockerfile
exists before trying to perform any substitution on it.
[1]: ac9f08d1c3
This commit separates inline attachments from normal attachments when
listing attachments in Action Mailer previews. For example, attachments
that were previously listed like
> Attachments: logo.png file1.pdf file2.pdf
will now be listed like
> Attachments: file1.pdf file2.pdf (Inline: logo.png)
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
There was many public reports of 15-25% latency improvements for Rails
apps that did enable Ruby 3.2 YJIT, and in 3.3 it's even better.
Following https://github.com/ruby/ruby/pull/8705, in Ruby 3.3 YJIT
is paused instead of disabled by default, allowing us to enable it
from an initializer.
Remove the option `config.public_file_server.enabled` from the generators for all environments, as the value is the same in all environments.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
In 11a6adc4fb custom code was added to
restrict values for some `rails new` options.
We don't need to implement this when it's already supported by Thor.
This also adds `none` as an option to the asset_pipeline as used in:
`railties/test/generators/shared_generator_tests.rb:320`.
* Conditionally print `$stdout` when invoking `run_generator`
In an effort to improve the developer experience when debugging
generator tests, we add the ability to conditionally print `$stdout`
instead of capturing it.
This allows for calls to `binding.irb` and `puts` work as expected.
```sh
PRINT_STDOUT=true ./bin/test test/generators/actions_test.rb
```
* Update railties/CHANGELOG.md
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
* Rename environment variable
* Update generators guides.
* Update guides
---------
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
Before, using the default `puma/config.rb` generated by `rails new`,
Puma would fail to boot in production with this error:
```
./config/puma.rb:16:in `block in _load_from': uninitialized constant Puma::DSL::Concurrent (NameError)
from ./config/puma.rb:16:in `fetch'
from ./config/puma.rb:16:in `_load_from'
```
This was because `Concurrent.physical_processor_count` was being
referenced before the `Concurrent` constant was initialized.
Fix by requiring `concurrent-ruby` just before the `Concurrent` constant
is needed.
Fixes#49323
* Add Bun support to `rails new -j` generator
* Add additional generation consideration for Bun
* Use development gems to test the whole workflow
* Remove custom gems from local testing
* Revert lock
* Revert errant custom gem declaration
* Fix linting errors
* Fix remnants of bad merge
* Always use latest bun
* Update actioncable/lib/rails/generators/channel/channel_generator.rb
Co-authored-by: Cadu Ribeiro <mail@cadu.dev>
* Update guides/source/working_with_javascript_in_rails.md
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
* Only use the latest bun if nothing is specified
* Hardcode known good version
---------
Co-authored-by: Cadu Ribeiro <mail@cadu.dev>
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
To avoid accidental writing to the production database, I always start
rails console in sandbox mode. I only start rails console in non-sandbox
mode when I'm sure I want to write to the production database.
`sandbox_by_default` option is added to start rails console in sandbox
mode by default. With this option turned on, `--no-sandbox` must be
specified to start rails in non-sandbox mode.
Note that this option is ignored when rails environment is development
or test.
As of Selenium 4.6, [the Selenium Manager is capable of managing Chrome
Driver installations and integrations][readme]. As of Selenium 4.11, the
Selenium Manager is capable of [capable of resolving the Chrome for
Testing installation][] path.
By omitting the `gem` declaration from the `Gemfile.tt`, newly generated
applications and applications updating their `Gemfile` in lockstep with
newer Rails versions can shed the dependency and avoid test failures
introduced by newly released Chrome versions (like, for example,
[titusfortner/webdrivers#247][]).
[readme]: 43f8ac436c (update-selenium-manager)
[titusfortner/webdrivers#247]: https://github.com/titusfortner/webdrivers/issues/247
[capable of resolving the Chrome for Testing installation]: https://github.com/rails/rails/pull/48847#issuecomment-1656756862
Co-authored-by: Titus Fortner <titusfortner@users.noreply.github.com>
The new syntax allows you to filter tests by line ranges. For example, the
following command runs tests between line 10 to 20.
```bash
$ rails test test/models/user_test.rb:10-20
```
Co-authored-by: Seonggi Yang <seonggi.yang@gmail.com>
Co-authored-by: Ryohei UEDA <ueda@anipos.co.jp>
Co-authored-by: oljfte <oljfte@gmail.com>
XHR requests other than GET or POST have issues when using 302
(e.g browsers trying to follow the redirect using the
original request method resulting in double PATCH/PUT)
This should be reverted when / if
https://github.com/rails/rails/pull/45393 is merged
This middleware has been logging at a FATAL level since the first
[commit][1] in Rails (the code originally lived in
actionpack/lib/action_controller/rescue.rb). However, FATAL is
documented in the Ruby Logger [docs][2] as being for "An unhandleable
error that results in a program crash.", which does not really apply to
this case since DebugExceptions is handling the error. A more
appropriate level would be ERROR, which the Ruby Logger docs describe as
"A handleable error condition."
This commit introduces a new configuration for the DebugExceptions log
level so that new apps will have it set to ERROR by default and ERROR
can eventually be made the default.
[1]: db045dbbf6
[2]: https://ruby-doc.org/3.2.1/stdlibs/logger/Logger/Severity.html
When calling `Rails.application.config#inspect` it will show all
attributes, including @secret_key_base after 21c3455054
By overriding the `inspect` method to only show the class name we can
avoid accidentally outputting sensitive information.
Before:
```ruby
Rails.application.config.inspect
"#<Rails::Application::Configuration:0x00000001132b02a0 @root=... @secret_key_base=\"b3c631c314c0bbca50c1b2843150fe33\" ... >"
```
After:
```ruby
Rails.application.config.inspect
"#<Rails::Application::Configuration:0x00000001132b02a0>"
```
Rails `secrets` have been deprecated in favor of `credentials`.
For the local environment the `secret_key_base` is now be stored in
`Rails.config.secret_key_base` instead of the deprecated
`Rails.application.secrets.secret_key_base`.
I will admit to deploying an app into production and leaving it there for weeks before realizing that authenticated traffic was being transported un-secured HTTP. I'd been operating under the false assumption that `config.force_ssl` would be `true` in production by default for new apps.
Suggesting this change to gauge interest and start a conversation. Since this option was introduced, the state of the web has really changed with Let's Encrypt certificates, and HTTPS has become table stakes for most hosting services. It feels like the time is right to enable Strict-Transport-Security by default for new apps.
Co-authored-by: Aaron Patterson <aaron@rubyonrails.org>
Co-authored-by: Guillermo Iguaran <guilleiguaran@gmail.com>
Co-authored-by: vinibispo <vini.bispo015@gmail.com>
TangRufus