* Update description for filter_parameter_logging
* Update railties/lib/rails/generators/rails/app/templates/config/initializers/filter_parameter_logging.rb.tt
Thanks Rob!!. I did all this in the github ui and was a little out of sorts with the wrapping.
Co-authored-by: Rob Zolkos <rob@zolkos.com>
---------
Co-authored-by: Rob Zolkos <rob@zolkos.com>
Co-authored-by: Rafael Mendonça França <rafael@rubyonrails.org>
- ## Context
While working on https://github.com/rails/rails/pull/44695, I
realised that Broadcasting was still a private API, although it’s
commonly used. Rafael mentioned that making it public would require
some refactor because of the original implementation which was hard
to understand and maintain.
### Changing how broadcasting works:
Broadcasting in a nutshell worked by “transforming” an existing
logger into a broadcasted one.
The logger would then be responsible to log and format its own
messages as well as passing the message along to other logger it
broadcasts to.
The problem with this approach was the following:
- Heavy use of metaprogramming.
- Accessing the loggers in the broadcast wasn’t possible.
Removing a logger from the broadcast either.
- More importantly, modifying the main logger (the one that broadcasts
logs to the others) wasn’t possible and the main source of
misunderstanding.
```ruby
logger = Logger.new(STDOUT)
stderr_logger = Logger.new(STDER))
logger.extend(AS::Logger.broadcast(stderr_logger))
logger.level = DEBUG # This modifies the level on all other loggers
logger.formatter = … # Modified the formatter on all other loggers
```
To keep the contract unchanged on what Rails.logger returns, the new
BroadcastLogger class implement duck typing with all methods
that has the vanilla Ruby Logger class.
It's a simple and boring PORO that keeps an array of all the loggers
that are part of the broadcast and iterate over whenever a log is
sent.
Now, users can access all loggers inside the broadcast and modify
them on the fly. They can also remove any logger from the broadcast
at any time.
```ruby
# Before
stdout_logger = Logger.new(STDOUT)
stderr_logger = Logger.new(STDER)
file_logger = Logger.new(“development.log”)
stdout_logger.extend(AS::Logger.broadcast(stderr_logger))
stdout_logger.extend(AS::Logger.broadcast(file_logger))
# After
broadcast = BroadcastLogger.new(stdout_logger, stderr_logger, file_logger)
```
I also think that now, it should be more clear for users that the
broadcast sole job is to pass everything to the whole loggers in
the broadcast. So there should be no surprise that all loggers in
the broadcast get their level modified when they call
`broadcast.level = DEBUG` .
It’s also easier to wrap your head around more complex setup such
as broadcasting logs to another broadcast:
`broadcast.broadcast_to(stdout_logger, other_broadcast)`
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
All the other VERSION ARGS in the Dockerfile are pure version numbers.
Any other additions are handled elsewhere.
Arguably, this is just cosmetic/foolish consistency, but it is a source
of subtle bugs. For example, the fallback if `bun -version` fails is
defined here:
af1d77abfb/railties/lib/rails/generators/app_base.rb (L19)
Note the _lack_ of bun_v, which ultimately will cause the docker build
to fail.
Change mentions of `app/views/shared` in the guides to be
`app/views/application` instead. View partials rely on the same
[Template Inheritance][] as their template counterparts, so the guides
should encourage end-users to benefit from that inheritance.
> This makes `app/views/application/` a great place for your shared
> partials, which can then be rendered in your ERB as such:
>
```html+erb
<%# app/views/admin/products/index.html.erb %>
<%= render @products || "empty_list" %>
<%# app/views/application/_empty_list.html.erb %>
There are no items in this list <em>yet</em>.
```
To enforce that template resolution, this commit also replaces
references to `shared/` with `application/` in the Rails test suite.
[Template Inheritance]: https://guides.rubyonrails.org/layouts_and_rendering.html#template-inheritance
## Motivation / Background
Continuous Integrating rubocop-rails_config after upgrading from Rails 7.0.7.2 to Rails 7.0.8 now fails:
```console
(snip)
rubocop --except=Style/StringLiterals,Style/FrozenStringLiteralComment .
cp ./test/fixture/.rubocop.yml rails_test/.rubocop.yml
cd rails_test
Inspecting 28 files
C...........................
Offenses:
Gemfile:71:1: C: [Correctable] Layout/EmptyLinesAroundBlockBody: Extra empty line detected at block body end.
28 files inspected, 1 offense detected, 1 offense autocorrectable
rake aborted!
```
https://github.com/toshimaru/rubocop-rails_config/actions/runs/6167995304/job/16739825926
Upon checking, redundant blank was added from version 7.0.8. This was `gem "webdrivers"` before 7.0.7.2.
### Rails 7.0.7.2
```console
$ ruby -v
ruby 3.3.0dev (2023-09-08T16:09:30Z master af5df9ee5e) [x86_64-darwin22]
$ cat Gemfile
# frozen_string_literal: true
source "https://rubygems.org"
gem "rails", "7.0.7.2"
$ bundle install
(snip)
$ bundle exec rails new example && cd $_
(snip)
% tail -n5 Gemfile
# Use system testing [https://guides.rubyonrails.org/testing.html#system-testing]
gem "capybara"
gem "selenium-webdriver"
gem "webdrivers"
end
```
### Rails 7.0.8
```console
$ cat Gemfile
# frozen_string_literal: true
source "https://rubygems.org"
gem "rails", "7.0.8"
$ bundle install
(snip)
$ bundle exec rails new example && cd $_
(snip)
% tail -n5 Gemfile
# Use system testing [https://guides.rubyonrails.org/testing.html#system-testing]
gem "capybara"
gem "selenium-webdriver"
end
```
This is reproduced with Rails 7.0.8, Rails 7.1.0.beta1 and the main branch.
I understand this might not be of utmost importance, but I would appreciate
it if it could be backported to the Rails 7.0 branch, if possible.
## Detail
The blank line is filled in by https://github.com/rails/rails/pull/48847.
This PR removes the redundant blank line from Gemfile of new app.
There are assertions that expected/actual arguments are passed in the
reversed order by mistake. Enabling the LiteralAsActualArgument rule
prevents this mistake from happening.
The existing tests were auto-corrected by rubocop with a bit of
indentation adjustment.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
* 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>
Follow-up to #47942.
This commit simplifies the normalization of regexp test filters.
Instead of modifying a given regexp to match a union of whitespace and
underscores, the regexp is unioned with the underscore-normalized
version of itself. This allows filters that include escaped spaces,
such as `/foo\ bar/`.
This commit also fixes `Rails::LineFiltering#run` such that
normalization isn't reapplied for every test suite. Thus
`normalize_declarative_test_filter` is no longer required to be
idempotent.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
Follow-up to [#47420][]
With the changes made in [#47420][], `has_secure_token` declarations can
be configured to execute in an `after_initialize` callback. This commit
proposed a new Rails 7.1 default: generate all `has_secure_token` values
when their corresponding models are initialized.
To preserve pre-7.1 behavior, applications can set
`config.active_record.generate_secure_token_on = :create`.
By default, generate the value when the model is initialized:
```ruby
class User < ApplicationRecord
has_secure_token
end
record = User.new
record.token # => "fwZcXX6SkJBJRogzMdciS7wf"
```
With `config.active_record.generate_secure_token_on = :create`, generate
the value when the model is created:
```ruby
# config/application.rb
config.active_record.generate_secure_token_on = :create
# app/models/user.rb
class User < ApplicationRecord
has_secure_token on: :create
end
record = User.new
record.token # => nil
record.save!
record.token # => "fwZcXX6SkJBJRogzMdciS7wf"
```
[#47420]: https://github.com/rails/rails/pull/47420
Co-authored-by: Hartley McGuire <skipkayhil@gmail.com>
`Kernel#caller` has linear performance based on how deep the
stack is. While this is a development only feature, it can end
up being quite slow.
Ruby 3.2 introduced `Thread.each_caller_location`, which lazily
yield `Backtrace::Location` objects.
Ref: https://bugs.ruby-lang.org/issues/16663
This is perfect for this use case as we are searching for the
closest frame that matches a pattern, saving us from collecting
the entire backtrace.
When we're editing the contents of encrypted files, we should use the
`Tempfile` class because it creates temporary files with restrictive
permissions. This prevents other users on the same system from reading
the contents of those files while the user is editing them.
[CVE-2023-38037]
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.
This `#use_puma?` check was [introduced][1] because Rails could
potentially display the wrong server URL in development if another host
or port is configured in `config/puma.rb`.
However, in Rack 3 the the name of the server class changed from
`Rack::Handler::Puma` to `Rackup::Handler::Puma`, which means that the
served_url is being logged again.
This commit fixes the check to accept either version of the class.
Additionally, puma was updated in Gemfile.lock because Puma 6.0.x prints
a deprecation warning about Rack::Handler that's fixed in 6.1.0.
[1]: 29648ff60e66c674b3cc49151df15dc100ffb4f4
