Execute `rails new myapp -S` and then upgrade the app by using the `app:update` task, `bin/rails c` results in `NoMethodError`.
```
$ bin/rails app:update
$ bin/rails c
Traceback (most recent call last):
44: from bin/rails:4:in `<main>'
(snip)
1: from /Users/tanimichi.tsukuru/ghq/github.com/moneyforward/moneyplus/config/initializers/assets.rb:4:in `<top (required)>'
/Users/tanimichi.tsukuru/ghq/github.com/moneyforward/moneyplus/vendor/bundle/ruby/2.5.0/gems/railties-5.2.0/lib/rails/railtie/configuration.rb:97:in `method_missing': undefined method `assets' for #<Rails::Application::Configuration:0x00007fcb8d3697e0> (NoMethodError)
Did you mean? asset_host
```
`yarn install --prod` removes dev deps,
so it's impossible to run `assets:precompile` with dev npm dependencies.
This change makes rake task pass NODE_ENV to yarn when explicitly set.
The previous documentation version listed only the default
registered extensions. This was misleading because if more extensions
get registered with
<tt>SourceAnnotationExtractor::Annotation.register_extensions</tt>,
they would be also taken into account. By saying that we consider
all registered extensions we document what happens in reality.
This change may only apply to POSIX-compliant systems.
Previously:
$ ls -l config/master.key
-rw-r--r-- 1 owner group 32 Jan 1 00:00 master.key
Now:
$ ls -l config/master.key
-rw------- 1 owner group 32 Jan 1 00:00 master.key
ImageProcessing gem is a wrapper around MiniMagick and ruby-vips, and
implements an interface for common image resizing and processing. This
is the canonical image processing gem recommended in [Shrine], and
that's where it developed from. The initial implementation was extracted
from Refile, which also implements on-the-fly transformations.
Some features that ImageProcessing gem adds on top of MiniMagick:
* resizing macros
- #resize_to_limit
- #resize_to_fit
- #resize_to_fill
- #resize_and_pad
* automatic orientation
* automatic thumbnail sharpening
* avoids the complex and inefficient MiniMagick::Image class
* will use "magick" instead of "convert" on ImageMagick 7
However, the biggest feature of the ImageProcessing gem is that it has
an alternative implementation that uses libvips. Libvips is an
alternative to ImageMagick that can process images very rapidly (we've
seen up 10x faster than ImageMagick).
What's great is that the ImageProcessing gem provides the same interface
for both implementations. The macros are named the same, and the libvips
implementation does auto orientation and thumbnail sharpening as well;
only the operations/options specific to ImageMagick/libvips differ. The
integration provided by this PR should work for both implementations.
The plan is to introduce the ImageProcessing backend in Rails 6.0 as the
default backend and deprecate the MiniMagick backend, then in Rails 6.1
remove the MiniMagick backend.
At SuSE, `$HOST` is set by default and is equal to `$HOSTNAME`.
https://www.suse.com/documentation/sled11/book_sle_admin/data/sec_adm_variables.html
Therefore, by default, it binds to hostname instead of `localhost`.
This seems not to be appropriate as default behavior.
In order to avoid the name of the environment variable being used,
I changed the environment variable from `HOST` to `BINDING`.
Fixes#29516.
There's no reason to block future versions of Capybara since we don't
_know_ they are going to break. How will we know if we have a
conservative option set? This change prevents us from blocking users who
want to upgrade in the future.
If @app.call returns an object that is saved (for e.g., in a constant), the mutation results in a continuing cycle of wrapping the body in Rack::BodyProxy, eventually leading to SystemStackError
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
On branch fix-return-response-mutation-rack-logger - Tue 3 Apr 2018 19:54:28 PDT by Geoff Lee <geoff.lee@lendesk.com>
ActionView::Template instances compile their source to methods on the
ActionView::CompiledTemplates module. To prevent leaks in development
mode, where templates can frequently change, a finalizer is added that
undefines these methods[1] when the templates are garbage-collected.
This is undesirable in the test environment, however, as templates don't
change during the life of the test. Moreover, the cost of undefining a
method is proportional to the number of descendants a class or module
has, since the method cache must be cleared for all descendant classes.
As ActionView::CompiledTemplates is mixed into every
ActionView::TestCase (or in RSpec suites, every view spec example
group), it can end up with a very large number of descendants, and
undefining its methods can become very expensive.
In large test suites, this results in a long delay at the end of the
test suite as all template finalizers are run, only for the process to
then exit.
To avoid this unnecessary cost, this change adds a config option,
`action_view.finalize_compiled_template_methods`, defaulting to true,
and sets it to false in the test environment only.
[1] 09b2348f7f/actionview/lib/action_view/template.rb (L118-L126)
If one created Rails 5.1 app and then updated to 5.2,
`secret_key_base` defined in `config/secrets.yml` is ignored for
`development` and `test` environment.
A change in `secret_key_base` in turn breaks
`Rails.application.key_generator`.
If one encrypt data in Rails 5.1, she cannot decrypt it in Rails 5.2
for `development` and `test` environment.
Now that we require Ruby over `2.3`, we can replace the current
suggestion methods we have with tooling from the `did_you_mean` gem.
There is a small user visible change and this is that we now offer a
single suggestion for misspelled options. We are suggesting fixes during
generator invocation and during a mistyped rails server rack handler. In
both cases, if we don't make a proper prediction on the first match, we
won't do so in the second or third one, so in my mind, this is okay.
Moves the configs_for and DatabaseConfig struct into it's own file. I
was considering doing this in a future refactoring but our set up forced
me to move it now. You see there are `mattr_accessor`'s on the Core
module that have default settings. For example the `schema_format`
defaults to Ruby. So if I call `configs_for` or any methods in the Core
module it will reset the `schema_format` to `:ruby`. By moving it to
it's own class we can keep the logic contained and avoid this
unfortunate issue.
The second change here does a double loop over the yaml files. Bear with
me...
Our tests dictate that we need to load an environment before our rake
tasks because we could have something in an environment that the
database.yml depends on. There are side-effects to this and I think
there's a deeper bug that needs to be fixed but that's for another
issue. The gist of the problem is when I was creating the dynamic rake
tasks if the yaml that that rake task is calling evaluates code (like
erb) that calls the environment configs the code will blow up because
the environment is not loaded yet.
To avoid this issue we added a new method that simply loads the yaml and
does not evaluate the erb or anything in it. We then use that yaml to
create the task name. Inside the task name we can then call
`load_config` and load the real config to actually call the code
internal to the task. I admit, this is gross, but refactoring can't all
be pretty all the time and I'm working hard with `@tenderlove` to
refactor much more of this code to get to a better place re connection
management and rake tasks.
In a three-tier config environment
`configurations[environment].presence` will return `{ :primary => {
:key => value, :key => value }, :secondary => { :key => value, :key =>
value} }, which means it's not given a single config to connect to.
If we flip these however it will connect to primary because that's the
default connection, and on a two tier it will be `nil` so the code will
select the connection from the configurations rather than the
connection.
