Because the TestUnit::Runner is used to run the tests from Rake test
tasks, we don't need to set the Rails environment based on the name of
the task anymore.
Co-authored-by: Adrianna Chang <adrianna.chang@shopify.com>
If the media attribute is omitted, the default for web browsers is "all", meaning that by default links apply to all media.
Before:
```ruby
> stylesheet_link_tag "style"
=> <link href="/assets/style.css" media="screen" rel="stylesheet" />
```
After:
```ruby
> stylesheet_link_tag "style"
=> <link href="/assets/style.css" rel="stylesheet" />
```
The current behavior is not going to change for existing applications.
For newly built applications, the media attribute is not going to be added by default. Which can be configured using the following:
```
Rails.application.config.action_view.stylesheet_media_default = false
```
Renaming test containing flag
Updating other test referencing master branch
Add notice that --master is deprecated, but still working the same as --main
Only set @main if it's nil
Making warn wildcard
I think a hidden aliaes would be just as good
Improving description & fixing rubocop error
Forgot comma
Deprecation warning was kind of hard - so just doing alias for now
rubocop -a
Before this commit, Rails test Rake tasks only load the test files, and
the tests only run in an at_exit hook via minitest/autorun.
This prevents conditionally running tasks only when tests pass, or even
more simply in the right order. As a simple example, if you have:
task default: [:test, :rubocop]
The rubocop task will run after the test task loads the test files but
before the tests actually run.
This commit changes the test Rake tasks to shell out to the test runner
as a new process.
This diverges from previous behavior because now, any changes made in
the Rakefile or other code loaded by Rake won't be available to the
child process. However this brings the behavior of `rake test` closer to
the behavior of `rails test`.
Co-authored-by: Adrianna Chang <adrianna.chang@shopify.com>
When I was comparing 'defaults' for 6.1 in this method and our configuring
guide, I was confused that some active_storage options are missing.
This change doesn't bring any implementation changes and feels like
a cosmetic change. Please feel free to close this if you think so and don't
see that we could benefit this change.
As mentioned in
https://github.com/rails/rails/pull/40770#issuecomment-748347066 we
should default to SHA256 where SHA1 is used today. This switches over
the ActiveSupport::Digest to use SHA256 for new applications.
It also updates the constants to always refer to and use the OpenSSL
constants as well, as also discussed in that PR.
This change allows for configuration of the hash digest that is used in
the key generator for key derivation.
SHA1 is an outdated algorithm and security auditors tend to frown on
its usage. By allowing this to be configured, it becomes possible to
move to a more up to date hash mechanism.
While I don't think this has any current relevant security implications,
especially not with a proper random secret base, moving away from SHA1
makes conversations with auditors and FIPS compliance checks easier
since the best answer is always that an approved algorithm is used.
A rotation can be built using this change with an approach like the
following for encrypted cookies:
```ruby
Rails.application.config.active_support.key_generator_hash_digest_class = OpenSSL::Digest::SHA256
Rails.application.config.action_dispatch.cookies_rotations.tap do |cookies|
salt = Rails.application.config.action_dispatch.authenticated_encrypted_cookie_salt
secret_key_base = Rails.application.secrets.secret_key_base
key_generator = ActiveSupport::KeyGenerator.new(secret_key_base, iterations: 1000, hash_digest_class: OpenSSL::Digest::SHA1)
key_len = ActiveSupport::MessageEncryptor.key_len
secret = key_generator.generate_key(salt, key_len)
cookies.rotate :encrypted, secret
end
```
This turns the default into using SHA256 but also still accepts secrets
derived using SHA1.
The defaults for new apps is here changed to use SHA256. Existing apps
will keep using SHA1.
Follow-up to #40960.
This fixes a few different visual issues with links and table rows when
using dark mode.
Co-authored-by: Chris Seelus <chris@imeos.com>
In #38495, `ARGV` was isolated to prevent commands from depending on its
contents, which might be indeterminate. However, app templates may
depend on `ARGV`, so populate it before evaluating them.
Fixes#40945.
Prior to this commit, the
[ActionView::Helpers::UrlHelper#button_to][button_to] helper rendered
`<input type="submit">` elements when passed its contents as a String
argument, and rendered `<button type="submit">` elements when passed its
contents as a block.
This difference is subtle, and might lead to surprises.
Additionally, a `<form>` element's submitter can encode a `name`/`value`
pairing, which will be submitted as part of the request. When
`button_to` renders an `<input type="submit">` element, the "button"
content is rendered as a `[value]` attribute, which prevents any
meaningful data from being encoded.
Since it's a single `<button>` or `<input type="submit">` within a
`<form>`, missing out on that opportunity to encode information might
not be a show stopper, but ensuring that a `<button>` element is
rendered _without_ a default `[value]` attribute enables applications to
encode additional information that can be accessed JavaScript as
`element.value`, instead of a workaround like
`element.getAttribute("data-value")`.
Support rendering `input` elements with button_to
---
To support the original behavior of `button_to` rendering `<input
type="submit">` elements when invoked _without_ a block, expose the
`app.config.button_to_generates_button_tag` configuration flag.
By default, it's set to `true` and ensures that all `button_to` calls
render `<button>` elements. To revert to the original behavior, set it
to `false`.
[button_to]: https://api.rubyonrails.org/v6.0/classes/ActionView/Helpers/UrlHelper.html#method-i-button_to
Co-authored-by: Dusan Orlovic <duleorlovic@gmail.com>
Since #39746, the Spring binstub can be generated without having to run
`bundle install` first, and thus the `skip_bundle` option does not
prevent the Spring binstub from being generated. Therefore, explicitly
set the `skip_spring` option for plugin dummy apps.
Since #40646, `bin/yarn` manually searches `PATH` for the `yarn`
executable. In Windows environments, executables have an `.exe` file
extension, so we must search for `yarn.exe` as well.
Fixes#40942.
PR #39939 added support for the `Link` header being generated
automatically when using `stylesheet_link_tag` and
`javascript_include_tag`. However not everything should be
preloaded, e.g. a link to a legacy IE stylesheet has no need to be
preloaded because IE doesn't support the header and in some browsers it
will trigger the preload even though it's not used since it's inside an
IE conditional comment. This leads to increased bandwith costs and
slower application performance.
To allow more flexibility for sites that may have complex needs for the
`Link` header this commit adds a configuration option that disables it
completely and leaves it up to the application to decide how to handle
generating a `Link` header.
Because Bundler is a default gem, `require "bundler"` by itself will
load the default version of the gem, instead of the most recent version.
This can cause Rails commands to produce warnings like the following:
> Warning: the running version of Bundler (2.1.4) is older than the
> version that created the lockfile (2.2.2). We suggest you to upgrade
> to the version that created the lockfile by running
> `gem install bundler:2.2.2`.
Adding `gem "bundler"` allows the most recent version of the gem to be
loaded.
Based on discussion in https://github.com/rails/rails/issues/40795, it
looks like `yarn:install` is *always* run, even if the Rails project
disabled javascript and there is no `bin/yarn`.
Check for the existence of `bin/yarn` to decide if `yarn:install` should
be run or not.
The check for this is taken from `railties/lib/rails/app_updater.rb`,
where it does the same:
```ruby
options[:skip_javascript] = !File.exist?(Rails.root.join("bin", "yarn"))
```
One reason why it could be missing because Rails was upgraded but `rails
app:update` was not run.
Running `rails app:update:bin` should create it.
refs #40795
