Executes the first routes reload in middleware, or when the route set
url_helpers is called. Previously, this was executed unconditionally on
boot, which can slow down boot time unnecessarily for larger apps with
lots of routes.
Executes the first routes reload in middleware, or when the route set
url_helpers is called. Previously, this was executed unconditionally on
boot, which can slow down boot time unnecessarily for larger apps with
lots of routes.
This will greatly increase the visibility of Rails console commands and helpers,
and stop rely on IRB's internal components.
Extension API reference: https://github.com/ruby/irb/blob/master/EXTEND_IRB.md
And because we need to create new classes to use the new APIs, I also
moved all the IRB-specific code to a new file, `irb_console.rb`.
Use IRB.conf[:BACKTRACE_FILTER] for backtrace filtering in console
This change uses the new `IRB.conf[:BACKTRACE_FILTER]` to inject the backtrace
filtering logic into IRB. This avoids the need to patch IRB's internal
WorkSpace class.
Update changelog
In https://github.com/ruby/debug/issues/797, we found that requiring
`debug` automatically activates it, which could introduce runtime overhead
and cause memory bloat. And I think many users aren't aware of this and
could be taxed by this unnecessarily (e.g. having longer builds on CI).
Therefore, I propose to add `require: "debug/prelude"` after `debug`'s
Gemfile entry in the default Gemfile template. This way, users can
still use breakpoint methods like `debugger`, `binding.break`, and `binding.b`,
but the debugger won't be activated until a breakpoint is hit.
If running in an interactive console, the user will be given the option to correct the error and re-run the tests.
Co-authored-by: Gannon McGibbon <gannon.mcgibbon@gmail.com>
Skip generating a `test` job in ci.yml when a new application is
generated with the `--skip-test` option.
Co-authored-by: Rafael Mendonça França <rafael@rubyonrails.org>
rails-html-santizer is a dependency of Action View and a transitive
dependency of Action Text (via Action Pack), but may not be loaded
until after railties sets configuration defaults.
This change `require`s rails-html-sanitizer immediately before it's
needed, and avoids the possibly-incorrect assumption that
Rails::HTML::Sanitizer is already defined.
Closes#51246
Co-authored-by: Rafael Mendonça França <rafael@rubyonrails.org>
* Set `action_mailer.default_url_options` values in `development` and `test`.
Prior to this commit, new Rails applications would raise
`ActionView::Template::Error` if a mailer included a url built with a
`*_path` helper.
Since we already know [new apps will be served on `localhost:3000`][new
apps], we set this as the value in `development`.
In an effort to remain consistent with existing patters, we set the
`host` to `www.example.com` in `test.
[new apps]: 47300002db/README.md (L81)
* Update railties/lib/rails/generators/rails/app/templates/config/environments/development.rb.tt
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
---------
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
The .devcontainer folder includes everything needed to boot the app and do development in a remote container.
The container setup includes:
- A redis container for Kredis, ActionCable etc.
- A database (SQLite, Postgres, MySQL or MariaDB)
- A Headless chrome container for system tests
- Active Storage configured to use the local disk and with preview features working
If any of these options are skipped in the app setup they will not be included in the container configuration.
These files can be skipped using the `--no-devcontainer` option.
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
When working in a devcontainer, for system tests we need to manually set the host and port serving the application. Let's introduce a method for this, so we don't have to expose the implementation details of Capybara to the developer.
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
This reverts commit 6985c3bedf0d85c180d8b86a2fcd6b19e7251bd3, reversing
changes made to 3163bb735189eddd7c152a1e72bed7b4d052f7d4.
Reason: While we want to apply this change, it make bundle being more
strict about the ruby version. This is particularly problematic for
the devcontainer images that don't support defining which patch
version of ruby to install.
Right now, you can only say you want Ruby 3.2, which could mean
3.2.3 or 3.2.0. If for some reason the devcontainer image doesn't
match the patch version on `.ruby-version` it will fail to install.
We are planning to solve this problem by publishing our own
ruby images that allow defining the patch level, but until that
we can't apply this change.
Previously, new apps would have a Ruby version set in both the Gemfile
and the .ruby-version file. This duplication makes it more difficult to
quickly change an application's ruby version as users must remember to
update multiple files.
This commit updates the app generator's Gemfile to read the Ruby version
from the .ruby-version file. Since this feature was introduced in the
latest version of Bundler, it will only be enabled if a supported version
of Bundler is used.
Alternatively, another solution mentioned on the original PR adding
.ruby-version was that the .ruby-version file could be removed once
rvm/rbenv support reading the Ruby version from the Gemfile. This has a
downside that many other tools like chruby do not have plans to support
reading a Ruby version from the Gemfile, and so users of those tools
would have a worse experience if the .ruby-version file is removed.
Co-authored-by: Takumi Shotoku <sinsoku.listy@gmail.com>
- If an application has files named `*_test.rb` in the
"fixtures/files" folder, they were picked up to be loaded.
In most cases this would result in a LoadError as its likely
those files include code that can't be loaded.
At the moment, Rails::Rack::Logger tags the logger (if it's
ActiveSupport::TaggedLogging) for the duration of the @app.call, but
only fires the request.action_dispatch event later, on body close. That
means anything logged in request.action_dispatch handlers won't have the
same tags as the rest of the request.
Fix this by deferring the popping of tags into
finish_request_instrumentation, in the same way that finishing the
instrumentation handle is deferred.
Following the discussion in #50770, the new format will be:
`[dasherized-app-name]([colorized-env])>`
For example, if the app's module name is `MyApp`, the prompt will be:
`my-app(dev)>`, where the `dev` part will be colored.
Update railties/lib/rails/commands/console/console_command.rb
Co-authored-by: Jean Boussier <jean.boussier@gmail.com>
Update changelog
Prior to this commit, `bin/rails` would pass unrecognized bare options
on to Rake:
```console
$ bin/rails -v
Rails 7.2.0.alpha
$ bin/rails -V
rake, version 13.0.6
$ bin/rails -s
Running 0 tests in a single process (parallelization threshold is 50)
...
$ bin/rails -S
invalid option: -S
```
This commit changes `bin/rails` to print its help message when given an
unrecognized bare option:
```console
$ bin/rails -v
Rails 7.2.0.alpha
$ bin/rails -V
Usage:
bin/rails COMMAND [options]
You must specify a command. The most common commands are:
...
$ bin/rails -s
Usage:
bin/rails COMMAND [options]
You must specify a command. The most common commands are:
...
$ bin/rails -S
Usage:
bin/rails COMMAND [options]
You must specify a command. The most common commands are:
...
```
However, for backward compatibility, an exception has been made for the
`-T` / `--tasks` option:
```console
$ bin/rails -T
# Prints list of Rake tasks...
```
Addresses #50712.
Previously, some files put under `app` directory would contaminate the load paths.
This commit removes files from the default load paths set up by the Rails framework.
Now, only directories are included as default in the following paths:
* autoload_paths
* autoload_once_paths
* eager_load_paths
* load_paths
Previously, the Rails application would reload due to changes
in some files outside the autoload paths.
For instance, editing `app/README.md` would trigger a reload,
even though the reloaded classes and modules were identical
to those loaded previously.
This commit fixes this issue by ensuring the application reloads correctly
according to `Rails.autoloaders.main.dirs`, thereby preventing unnecessary reloads.
https://github.com/rails/rails/issues/37011#issuecomment-1322560651
* 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.
