In #39632, `boot.rb` was changed to load `bin/spring`, with the
intention of adding a check to Spring itself that would prevent Spring
from running in production environments. However, in a production
environment, the Spring gem may not be installed. Furthermore,
`bin/spring` may raise an error other than `LoadError` if it has been
overwritten by e.g. `bundle binstubs` as part of the deployment process.
Therefore, this commit adds the environment check to `boot.rb`.
This commit also changes the app generator to generate `bin/spring`
directly, instead of delegating to `bundle exec spring binstub`. This
addresses an issue with the `--skip-bundle` flag. Previously,
`--skip-bundle` caused `bin/spring` to not be generated. Thus the user
had to manually run `bundle exec spring binstub` later, though that was
not documented nor explained. Now, `bin/spring` is always generated.
Additionally, by guaranteeing that `bin/stub` is generated, we avoid the
need for `rescue LoadError` in `boot.rb`.
* Refactor railsrc file location to be xdg compliant
The XDG Base Directory Specification (which is currently used by
FOSS projects such as Git, Tmux, Pry, Rspec) provides a default
location for various file formats, including config/rc files.
This comment refactors app_generator.rb to load railsrc from
XDG_CONFIG_HOME if both XDG_CONFIG_HOME is set and rails/railrc
exists within the XDG_CONFIG_HOME location.
To maintain backwards compatibility it defaults back to ~/.railsrc
if either XDG_CONFIG_HOME is not set or there is no rails/railsrc.
* Refactor default_rc_file based on jonathanhefner PR feedback
* Update generators/rails/app/USAGE to explain railsrc XDG compliance
* Refactor default_rc_file based on sinsoku PR feedback
* Add test for ARGVScrubber.default_rc_file method
fileutils is required because tmpdir does not allow you to create a new
temp directory with a set title 'inside' another temporary directory, a
file is created for railsrc because tempfile creates a custom and unique
name preventing the specification of a file called 'railsrc'
Currently this test is failing because the ARGVScrubber class seems to
be loading directly from the gem (which still has the previous code)
rather than from the file itself. (loading the code in a pry session
and using show-method ARGVScrubber.default_rc_file reveals it is coming
from
gems/railties-6.0.3.3/lib/rails/generators/rails/app/app_generator.rb:536
instead of
railties/lib/rails/generators/rails/app/app_generator.rb
* Switch to double quote strings
* Add file deletion for argv_scrubber test
* Refactor test_xdg_config_no_custom_rc with jonathanhefner feedback
* Add Changelog for railsrc xdg-specification compliance
* Apply backtick and whitespace refactoring suggestsions from jonathanhefner
* Apply jonathanhefner suggested Changelog refactoring
[Rafael Mendonça França + Nick Wolf + Jonathan Hefner]
Currently when a new rails app is created it uses the app name as it and puts
it in the package.json name. According to npm and JS standards package names
do not have capital letters and should not be using the PascalCase that is
used in Rails app name. This change is to convert app name to using snake case
but with dashes
`Minitest.plugin_rails_init` sets `Minitest.backtrace_filter` to
`Rails.backtrace_cleaner` right before tests are run, overwriting the
value set in test_helper.rb.
`Rails.backtrace_cleaner` silences backtrace lines that do not start
with `Rails.root` followed by e.g. "lib/" or "test/". Thus when
`Rails.root` is a subdirectory of the project directory -- for example,
when testing a plugin that has a dummy app -- all lines of the backtrace
are silenced.
This commit adds a fallback such that when all backtrace lines are
silenced, the original `Minitest.backtrace_filter` is used instead.
Additionally, this commit refactors and expands existing test coverage.
Each stacked operation is a Proc object instead of operation name since fedde239dcee256b417dc9bcfe5fef603bf0d952,
and so we can now simply inline the target method for each operation
Right now it's already possible to set a digest class manually, but this
is not through a publicly supported and approved API. With these
configuration options, it is possible to configure a digest class to use
for digests inside Rails.
The reason for this is that it allows configuring other classes in
certain conditions like running in FIPS mode. FIPS disallows MD5 and
discourages SHA1. Even though this isn't used in Rails for security
related things, using newer hash algorithms means not having to explain
it to auditors which always makes life easier.
That's not the only reason though. If today Ruby is built and running
for example in an Ubuntu 18.04 FIPS approved environment, the default
Digest classes break, see https://bugs.ruby-lang.org/issues/13681 as
well.
By allowing a class to be configured, the following can be used so that
things work properly (using the new API proposed here):
```
Rails.application.config.active_support.hash_digest_class = OpenSSL::Digest::SHA256
```
This would then use the OpenSSL certified FIPS implementation as well.
.gitattributes files are a useful way to mark certain metadata about paths in a git repository (https://git-scm.com/docs/gitattributes). This can include all kinds of information, but one of the more useful ones is that linguist (https://github.com/github/linguist, the tool that powers the language statistics/diff view of GitHub) respects certain attributes. For example:
* `linguist-vendored` paths will not be counted toward the language statistics
* `linguist-generated` paths will not have their diff shown by default
These little niceties can be really helpful over time, so we should add it to the default app generator.
I recently learned that Rails logs at the :debug level (not the :info
level) by default in production environments. This is a surprising
behaviour, as other popular frameworks do not log at this level
by default. It would not be surprising if a developer accidentally
logged personally identifiable information (PII) in a production
environment due to this behaviour.
I noticed that [in 2014](https://github.com/rails/rails/pull/16622), the
Rails project made an intentional decision to set the default log level
to :debug. However, the landscape around logging PII has changed since
then with the introduction of legislation like GDPR, so I thought it
prudent to reopen this discussion.
Follow-up to #40143.
Rails Rake tasks are loaded for each new `Rake::Application` instance
via `Rails.application.load_tasks`. However, under the hood,
`Rails.application.load_tasks` used `require` instead of `load`, which
caused Rails tasks to be loaded for only the first `Rake::Application`
instance.
This commit changes the relevant `require` to `load`.
Fixes#40184.
In #39137, a new `Rake::Application` instance was created per Rake
command invocation. To ensure that the Rails tasks were defined for
each `Rake::Application`, `rails/tasks.rb` was loaded per instance.
However, `Rake::Application#load_rakefile` loads the application's
Rakefile, which should invoke `Rails.application.load_tasks`, which, in
turn, also loads the Rails tasks. When a Rake task is defined more than
once, all definition blocks are executed when the task is run. Hence,
Rails task blocks were being executed twice.
This commit removes the unnecessary load and avoids double execution.
Fixes#40136.
Fixes#40031
While removing deprecated non-symbol access to nested `config_for`
hashes in #37876, we also broke `config_for` for anyone using the
[safe_yaml] gem. The problem is that `safe_yaml` patches `YAML.load` in
a way that doesn't honor the `symbolize_names` options (I believe this
is on purpose, to prevent symbol-based DOS attacks).
In the description of #37876 there is mention of the fact that this was
the first place in Rails we used `symbolize_names`, and that
`deep_symbolize_keys` had been used in the past.
This commit switches over to `deep_symbolize_keys` to allow `config_for`
to continue working for people using [safe_yaml].
[safe_yaml]: https://rubygems.org/gems/safe_yaml
For example, for a plugin like `my_plugin`, this makes the
`MyPlugin::VERSION` constant available to all consumers by default.
This commit also replaces the default generated test with a test that
the developer is less likely to delete.
The `config/application.rb` file of a plugin test dummy app should be
the same as in a standard Rails app, with the exception of an additional
`require` statement to load the plugin itself. However, prior to this
commit, the plugin generator used a specialized template for a portion
of this file, which tended to drift out-of-sync with the standard app
generator's template. Specifically, this drift could result in missing
`require` statements of newer Rails frameworks when the plugin generator
was run with any `--skip-xxxx` option.
This commit changes the plugin generator to insert its additional
`require` statement into the standard `config/application.rb` file
generated by the app generator.
Engines are not applications, indeed 'Application < Engine', so it's the other way round.
The difference can be confusing anyway, so we should make sure the documentation is clear.
When passing a camelcased model name to a generator sometimes it's
impossible to inflect the casing. For example "BFF" will generate a
route for the controller BffsController, but the controller generated is
BfFsController.
The casing is impossible to inflect if both:
- a camelcased model name is passed to a generator
- `name.pluralize.underscore.singularize != name.underscore.singularize`
If this happens we raise an error. The error message explains the user
can either us an underscored name or add an inflection instead.
308 status code introduced in https://tools.ietf.org/html/rfc7538
preserves the request method unlike 301 status code which would convert
POST requests to GET.
This change swaps the CommonJS require() syntax in the Webpacker
application.js pack template file and in documentation examples with ES
module import syntax.
Benefits of this change include:
Provides continuity with the larger frontend community: Arguably, one of
the main draws in adopting Webpacker is its integration with Babel to
support ES module syntax. For a fresh Rails install with Webpacker, the
application.js file will be the first impression most Rails developers
have with webpack and Webpacker. Most of the recent documentation and
examples they will find online for using other libraries will be based
on ES module syntax.
Reduces confusion: Developers commonly add ES imports to their
application.js pack, typically by following online examples, which means
mixing require() and import statements in a single file. This leads to
confusion and unnecessary friction about differences between require()
and import.
Embraces browser-friendliness: The ES module syntax forward-looking and
is meant to be supported in browsers. On the other hand, require()
syntax is synchronous by design and not browser-supported as CommonJS
originally was adopted in Node.js for server-side JavaScript. That
webpack supports require() syntax is merely a convenience.
Encourages best practices regarding optimization: webpack can statically
analyze ES modules and "tree-shake", i.e., strip out unused exports from
the final build (given certain conditions are met, including
`sideEffects: false` designation in package.json).
Follow up to c07dff72278fb7f2a3c4c71212a0773a2b25c790.
Actually it is not the cop's fault, but we mistakenly use `^`, `$`, and
`\Z` in much places, the cop doesn't correct those conservatively.
I've checked all those usage and replaced all safe ones.
Silence Rake task backtraces, similar to Rails::BacktraceCleaner.
Application lines are preserved, but all other lines are hidden.
This also affects unrecognized tasks, causing the backtrace to be hidden
entirely. Closes#39524.
Co-authored-by: Petrik <petrik@deheus.net>
Applications may not have a primary configuration so we should not
assume there is one. In both these cases we can get the right connection
without that.
For the databases.rake file we want to re-establish a connection for the
environment we're in. The first config defined under an environment for
a multi-db app will win. This is already the case on application boot so
we should be consistent.
For the info.rb file we already have a connection so we can lookup the
adapter from the connection's db_config. If a primary hadn't existed
this would have thrown an exception.
Followup to https://github.com/rails/rails/pull/39535 which removed the
assumption there was a primary config from the schema cache load
railtie.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
Generators generate things, but what is meant by 'Stubbing out' might
confuse beginners and non-native English speakers.
While generated tests are stubs that should have an implementation, a
generated model is a valid model that doesn't require any changes.
Before #39304 was merged, backtraces would look like this:
```
$ be ruby -I lib:test test/controller/request_forgery_protection_test.rb -n test_ignores_trailing_slash_during_generation
Run options: -n test_ignores_trailing_slash_during_generation --seed 22205
E
Error:
PerFormTokensControllerTest#test_ignores_trailing_slash_during_generation:
NoMethodError: undefined method `have_cookie_jar?' for #<Object:0x00007f9ce19b9620>
/Users/aaron/git/rails/actionpack/lib/action_controller/test_case.rb:522:in `ensure in process'
/Users/aaron/git/rails/actionpack/lib/action_controller/test_case.rb:542:in `process'
/Users/aaron/git/rails/actionpack/lib/action_controller/test_case.rb:395:in `get'
test/controller/request_forgery_protection_test.rb:1005:in `test_ignores_trailing_slash_during_generation'
rails test test/controller/request_forgery_protection_test.rb:1004
Finished in 0.213230s, 4.6898 runs/s, 0.0000 assertions/s.
1 runs, 0 assertions, 0 failures, 1 errors, 0 skips
```
After #39304 was merged they look like this:
```
$ be ruby -I lib:test test/controller/request_forgery_protection_test.rb -n test_ignores_trailing_slash_during_generation
Run options: -n test_ignores_trailing_slash_during_generation --seed 62892
E
Error:
PerFormTokensControllerTest#test_ignores_trailing_slash_during_generation:
NoMethodError: undefined method `have_cookie_jar?' for #<Object:0x00007fa6d60193c8>
rails test test/controller/request_forgery_protection_test.rb:1004
Finished in 0.211953s, 4.7180 runs/s, 0.0000 assertions/s.
1 runs, 0 assertions, 0 failures, 1 errors, 0 skips
```
This patch reverts the part of #39304 that removes the backtrace.
- Add the configuration option for annotating templates with file names to the generated app.
- Add `annotate_rendered_view_with_filenames` option to configuring guide.
* Add default ENV variable option with BACKTRACE to turn off backtrace cleaning when debugging framework code
* Use runner as the example
Although I think we should consider dropping -b in tests and just relying on this more general option for sidestepping the backtrace cleaner.
I'm not sure about this one. The gist is, minitest's
UnexpectedError#message includes a backtrace but the reporter tests
here expect there not to be one in inline output.
Personally, I think that's wrong as it removes information you'd want
to debug, but this might be a philosophical difference with the rails
test ethos... or it might just be aesthetic.
I am happy to back out this change and fix the tests if you'd rather.
* Adds a rails test:all rake task
This task runs all tests, including system tests.
* Better placement + slight tweak of the comment
Co-authored-by: David Heinemeier Hansson <david@loudthinking.com>
Register a callback that will get called right after generators has
finished.
This is useful if users want to process generated files.
For example, can execute an autocorrect of RuboCop for generated files
as like following.
```ruby
config.generators.after_generate do |files|
system("bundle exec rubocop --auto-correct " + files.join(" "), exception: true)
end
```
This makes test file patterns configurable via two environment variables:
`DEFAULT_TEST`, to configure files to test, and `DEFAULT_TEST_EXCLUDE`,
to configure files to exclude from testing.
These values were hardcoded before, which made it difficult to add
new categories of tests that should not be executed by default (e.g:
smoke tests).
It uses environment variables instead of regular Rails config options
because Rails environment is not available when the Runner builds the
list of files to test (unless using Spring). A nicer solution would be
making sure that the Rails environment is always loaded when the runner
starts. This is a first simple step to make these paths configurable for
now
This way at least you could override defaults in `config/boot.rb`:
```ruby
ENV["DEFAULT_TEST_EXCLUDE"] = "test/{dummy,smoke,system}/**/*_test.rb
```
Co-authored-by: Jeremy Daer <jeremydaer@gmail.com>
Rake stores the current top-level task and arguments in global state.
Invoking another top-level task within the same process requires
overwriting this state. Doing so indiscriminately can cause incorrect
behavior, such as infinitely repeating the original task. In
particular, this is a problem when running one task from another via
`rails_command "...", inline: true`.
The solution is to save and restore the global state in each call to
`RakeCommand.perform` using the `Rake.with_application` method.
Fixes#39128.
37913 added the possibility to deeply merge configurations by grouping
them within a shared section. This powerful alternative was not reflected
in any documentation, which made my team think it was not possible until
I found out this feature after looking at the source code.
This patch reflects this change in the documentation so that it is
easier for other developers to know about this behavior.
These have been required in the generated test environment config since
1c7207a22faca3f07ee9aee1dc00a5b01286de2f, but the generated development
config also uses them (albeit inside a conditional), and the generated
production config contains a comment which uses them.
More generally, we shouldn't require core extensions in one environment
and not others, since applications with `config.active_support.bare`
enabled could rely on them implicitly and exhibit inconsistent behaviour
across environments.
Previously, a test runner argument had to contain a forward slash to be
recognized as a path. Now, backslashes will also be considered,
enabling the use of Windows-style paths.
Fixes#38243.
This was added to the defaults for new applications in
e2cdffce3d4086e33db172cf9722e84f86a80e84, but we also need an entry in
the new framework defaults initializer for upgrading applications.
Since 04cfbc807f0567af5a27e8ba45eab52f7b9e6618, a keepfile is generated
in `tmp/pids/` to ensure that the directory always exists. However, the
gitignore pattern for `/tmp/*` meant it wasn't tracked in git.
To override that pattern we have to allow the `tmp/pids/` directory,
ignore everything inside it, then finally allow `tmp/pids/.keep` again.
From the instructions in database.yml, it is not clear that Rails will
automatically use ENV['DATABASE_URL'] if it is present.
This commit rewords the instructions to clarify that Rails will do so.
The `rdoc lib` command produces nearly the same output as `rake rdoc`.
The `rdoc lib` command also has the benefit of being standard, whereas
Rake subcommands can vary from project to project. Since the purpose of
either command is to support local development, as opposed to generating
official docs for consumption by e.g. rubygems, the standard command
seems preferable.
Note that the `rdoc` command outputs to the doc/ directory by default,
so this commit also adds that directory to the plugin .gitignore file.
* require, require_relative, load by double quotes
We're getting rid of all single quote usage, unless it serves a specific purpose, as per the general style guide.
The `rails test` command scans its arguments for test paths to load
before handing off option parsing to Minitest. To avoid incorrectly
interpreting a `-n /regex/` pattern as an absolute path to a directory,
it skips arguments that end with a slash. However a relative path ending
in a slash is not ambiguous, so we can safely treat those as test paths.
This is especially useful in bash, where tab completing a directory
leaves a trailing slash in place.
This fixes an exception when generating a new app on Ruby 2.8. Before
this commit, I get this exception:
```
$ be ruby railties/exe/rails new ~/git/fix-bug --dev
...
...
Traceback (most recent call last):
31: from railties/exe/rails:10:in `<main>'
30: from railties/exe/rails:10:in `require'
29: from /Users/aaron/git/rails/railties/lib/rails/cli.rb:18:in `<top (required)>'
28: from /Users/aaron/git/rails/railties/lib/rails/command.rb:45:in `invoke'
27: from /Users/aaron/git/rails/railties/lib/rails/command/base.rb:69:in `perform'
26: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
25: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
24: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
23: from /Users/aaron/git/rails/railties/lib/rails/commands/application/application_command.rb:26:in `perform'
22: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
21: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/group.rb:232:in `dispatch'
20: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/invocation.rb:134:in `invoke_all'
19: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/invocation.rb:134:in `map'
18: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/invocation.rb:134:in `each'
17: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/invocation.rb:134:in `block in invoke_all'
16: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
15: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
14: from (eval):1:in `run_webpack'
13: from /Users/aaron/git/rails/railties/lib/rails/generators/app_base.rb:419:in `run_webpack'
12: from /Users/aaron/git/rails/railties/lib/rails/generators/actions.rb:255:in `rails_command'
11: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/actions.rb:197:in `in_root'
10: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/actions.rb:187:in `inside'
9: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/2.8.0/fileutils.rb:139:in `cd'
8: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/2.8.0/fileutils.rb:139:in `chdir'
7: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/actions.rb:187:in `block in inside'
6: from /Users/aaron/.rbenv/versions/ruby-trunk/lib/ruby/gems/2.8.0/gems/thor-1.0.1/lib/thor/actions.rb:197:in `block in in_root'
5: from /Users/aaron/git/rails/railties/lib/rails/generators/actions.rb:256:in `block in rails_command'
4: from /Users/aaron/git/rails/activesupport/lib/active_support/core_ext/kernel/reporting.rb:15:in `silence_warnings'
3: from /Users/aaron/git/rails/activesupport/lib/active_support/core_ext/kernel/reporting.rb:28:in `with_warnings'
2: from /Users/aaron/git/rails/activesupport/lib/active_support/core_ext/kernel/reporting.rb:15:in `block in silence_warnings'
1: from /Users/aaron/git/rails/railties/lib/rails/generators/actions.rb:257:in `block (2 levels) in rails_command'
/Users/aaron/git/rails/railties/lib/rails/command.rb:31:in `invoke': wrong number of arguments (given 3, expected 1..2) (ArgumentError)
```
After this commit, things seem to work.
Putting ".localhost" at the end causes 4 IPAddr::InvalidAddressError
exceptions to be raised and rescued during every request when the
HostAuthorization middleware attempts to compare an IPAddr with a
"localhost" string.
This adds a StringInquirer subclass EnvironmentInquirer that
predefines the three default environments as query methods, in
order to avoid dispatching through `method_missing` for every call
to those methods. The original StringInquirer was not modified due
to the side effects of having new env-related methods on it. This
new class was not implemented using lazy method definition to
avoid the open-ended possibility of defining a new method for all
query calls. The three default environments should cover a high
percentage of real-world uses, and users with custom environments
could add their own to this class.
Fixes#37803.
Currently the `rails new` generator supports options `—dev` and `—edge`.
`—dev` points to one’s local rails setup and `--edge` points to the latest stable Rails branch.
However, in the Rails community we often think of the ‘edge’ as the latest merged master. We can see as much in Shopify’s fantastic article showing how they point to the latest master version of Rails: https://engineering.shopify.com/blogs/engineering/living-on-the-edge-of-rails
I would originally have recommended changing ‘edge’ to point to master, as it has tripped me up on numerous occasions now.
However I would rather add the desired functionality then change the current edge functionality.
Therefore this PR adds the `—master` flag.
It is intended to do exactly as `edge` does, simply with the changethat it points to Rails’ master branch instead of latest stable (i.e. 6_0_stable)
Whenever developers see a new feature in Rails, such as the recently committed horizontal sharding (which prompted my PR), we would love to spin up a new Rails App to try out these new features.
This command would allow us to jump right in with no configuration and offer our testing of the features, even those of us who aren’t able to spend a lot of time on OSS support.
I have so. many. regrets. about using `spec_name` for database
configurations and now I'm finally putting this mistake to an end.
Back when I started multi-db work I assumed that eventually
`connection_specification_name` (sometimes called `spec_name`) and
`spec_name` for configurations would one day be the same thing. After
2 years I no longer believe they will ever be the same thing.
This PR deprecates `spec_name` on database configurations in favor of
`name`. It's the same behavior, just a better name, or at least a
less confusing name.
`connection_specification_name` refers to the parent class name (ie
ActiveRecord::Base, AnimalsBase, etc) that holds the connection for it's
models. In some places like ConnectionHandler it shortens this to
`spec_name`, hence the major confusion.
Recently I've been working with some new folks on database stuff and
connection management and realize how confusing it was to explain that
`db_config.spec_name` was not `spec_name` and
`connection_specification_name`. Worse than that one is a symbole while
the other is a class name. This was made even more complicated by the
fact that `ActiveRecord::Base` used `primary` as the
`connection_specification_name` until #38190.
After spending 2 years with connection management I don't believe that
we can ever use the symbols from the database configs as a way to
connect the database without the class name being _somewhere_ because
a db_config does not know who it's owner class is until it's been
connected and a model has no idea what db_config belongs to it until
it's connected. The model is the only way to tie a primary/writer config
to a replica/reader config. This could change in the future but I don't
see value in adding a class name to the db_configs before connection or
telling a model what config belongs to it before connection. That would
probably break a lot of application assumptions. If we do ever end up in
that world, we can use name, because tbh `spec_name` and
`connection_specification_name` were always confusing to me.
Follow-up to #38463.
By isolating ARGV, we guard against commands inadvertently depending on
prior ARGV contents. Any such command will now behave consistently when
run via `Rails::Command.invoke`, whether coming from the Rails CLI or
from library code. Likewise, any ARGV mutations done by a command will
not affect code that executes after `Rails::Command.invoke`.
A .ruby-version file is not useful in a plugin dummy app because the
plugin itself dictates the required Ruby version. Indeed, the dummy app
.ruby-version file might fall out of sync with whatever the plugin
dictates, and thus result in unexpected "Could not find gem" errors when
running commands from within the dummy app directory.
Follow-up to #38429.
`Rails::Command.invoke` passes arguments through to the appropriate
command class. However, some command classes were ignoring those
arguments, and instead relying on the contents of ARGV. In particular,
RakeCommand expected ARGV to contain the arguments necessary to the Rake
task, and no other arguments. This caused the `webpacker:install` task
to fail when the `--dev` option from `rails new --dev` remained in ARGV.
This commit changes the relevant command classes to not rely on the
previous contents of ARGV. This commit also adds a missing `require`
for use of `Kernel#silence_warnings`.
Fixes#38459.
When is use a scaffold_controller add the routes as resources to the
config/route.rb
Also enable to use --skip-routes if doesn't want include the resources
into the config/routes.rb file.
The documentation for Rails::Generators::TestCase suggests using tmp/ as
the destination directory when testing generators. Many plugins test
generators, so it makes sense to include tmp/ in the default .gitignore.
Rails has a number of places where a YAML configuration file is read,
then ERB is evaluated and finally the YAML is parsed.
This consolidates that into one common class.
Co-authored-by: Kasper Timm Hansen <kaspth@gmail.com>
If the plugin or one of its dependencies requires a version of Rake
that is different than the version executing the Rakefile,
`require 'bundler/setup'` will raise a LoadError with a helpful error
message like: "You have already activated rake 13.0.1, but your Gemfile
requires rake 12.3.3. Prepending `bundle exec` to your command may solve
this."
If that LoadError is swallowed, another LoadError will eventually be
raised with a less helpful / more confusing error message like: "cannot
load such file -- rake".