* doc: fix CHANGELOG message for sessions generator
* fix: Sessions generator adds bcrypt more robustly
Use Thor's `uncomment_lines` instead of `gsub_file`.
If the Gemfile does not contain bcrypt, either commented or
uncommented, then run `bundle add bcrypt`.
Make sure all bundler commands run within `Bundler.with_original_env`
to avoid bundler resolution problems while trying to resolve bundler
dependencies. Typically the failure mode here is seeing:
> Could not find bcrypt-3.1.20 in cached gems or installed locally (Bundler::GemNotFound)
while bootstrapping the process that will run bundle-install or bundle-add.
* Remove channels from default app/ structure
Now that Hotwire is the default, the majority of apps won't need custom
channels. And those that do can get the files back via the generator.
* Remove trailing space
* Remove additional needless elements
* No longer to be generated
* No longer generated
Add a new script default folder to hold one-off or general purpose
scripts, such as data migration scripts, cleanup scripts, etc. Also add
a script generator to create such scripts.
Co-authored-by: Haroon Ahmed <haroon.ahmed25@gmail.com>
The overhead isn't necessary for development when not using the routes
command. We can omit it entirely by checking for existence of the routes
command constant.
Currently, we use both Thor and Rake for `bin/rails` commands.
We eventually want to get all the built-ins task promoted to Thor Commands.
This migrates the `stats` task to Thor.
References https://github.com/rails/rails/pull/52012#issuecomment-2183415161
Revert "Merge pull request #52033 from Shopify/amend_lazy_routes_changelog"
This reverts commit 743128b2307b6e1bd59acb9dc8358592d264c573, reversing
changes made to 6622075802bdcca22ab3e32ef6e3f6d2b9a881f8.
Revert "Merge pull request #52012 from Shopify/defer_route_drawing"
This reverts commit 6622075802bdcca22ab3e32ef6e3f6d2b9a881f8, reversing
changes made to 5dabff4b7bf4cc5e2e552efb78c6a3f3e44bed37.
When there are no fields:
* Omit blank line in migration prior to "t.timestamps"
* Omit leading and trailing spaced in empty hashes in
create and update controller and api functional tests
Co-authored-by: zzak <zzakscott@gmail.com>
Follow up to [#50527][]
Highlight the presence of the `yield :head` pattern established by
`turbo-rails` and adopted by Rails as part of [#50527][].
New applications will generate their application layout with `yield
:head`, so mention that in the documentation.
Also include the `yield :head` call in generated plugin layouts.
[#50527]: https://github.com/rails/rails/pull/50527
Currently, `ENV["SELENIUM_HOST"]` is evaluated when generating a file. So
the result was the following.
```
driven_by :selenium, using: :headless_chrome, screen_size: [ 1400, 1400 ], options: {
browser: :remote,
url: "http://:4444"
}
```
This PR fixes to output the URL setting just as a string. The after
result is the following.
```
driven_by :selenium, using: :headless_chrome, screen_size: [ 1400, 1400 ], options: {
browser: :remote,
url: "http://#{ENV["SELENIUM_HOST"]}:4444"
}
```
The documentation on ActiveSupport::MessageVerifier used the “sensitive data” string as an example; that wording might induce the developer to think we’re dealing with encryption, while the payload is actually only Base64 encoded and is not protected at all.
We also improve the documentation on ActiveRecord::SignedId, which uses MessageVerifier and thereby will also expose the ID as encoded cleartext, making explicit that it’s not encryption, only signing.
Lastly, we refer the developer to MessageEncryptor if the payload needs to be encrypted.
This is a partial revert of #41083.
`puma.rb` may update by users, but Rails has improved `puma.rb` sometimes.
For example, 06d614ada9e4609ff83659e842f48af3232a03a5 and f719787c582839fd2fcd886d70b43da3ddad2ceb.
To allow users to know those improvements, I think we should update
`puma.rb` by `app:update`.
The [deprecated secrets removal][1] ended up removing a bit of
non-deprecated functionality related to config.secret_key_base:
- the original implementation prioritized the value of
config.secret_key_base over other sources in all environments
- if unset, the value of config.secret_key_base would be updated to
whichever fallback value was found
The new implementation only sets config.secret_key_base to a fallback
value when Rails.env.local?, and never considers it at all in
production.
This commit aims to restore this missing functionality as well as
simplify the implementation:
- Rails.application.secret_key_base now always delegates to
config.secret_key_base (like the pre-secret-removal implementation)
- secret_key_base validation was moved from the reader to the writer
- config.secret_key_base now handles setting itself to a fallback value
when unset
- In addition, generate_local_secret was simplified because it
previously did 3 things: file manipulation, setting
config.secret_key_base, and returning a value. Now it only creates the
file if necessary and returns the value stored in it
The new implementation has an additional benefit, which is that manually
set config.secret_key_base values are now validated, whereas previously
only fallback values were validated.
[1]: 0c76f17f2dbf0d7ad90c890e6f334743cacce41f
Co-authored-by: Petrik <petrik@deheus.net>
Before:
```
(called from Rails::ConsoleMethods.include at /home/zzak/code/rails/railties/lib/rails/console/methods.rb:6)
```
After:
```
(called from block in <class:Engine> at /home/zzak/.rbenv/versions/3.4.0/lib/ruby/gems/3.4.0+0/bundler/gems/mission_control-jobs-7295d75ed735/lib/mission_control/jobs/engine.rb:73)
```
Co-authored-by: Wojciech Wnętrzak <w.wnetrzak@gmail.com>
