Since bundler 1.12.0, the gemspec is validated so the `bundle install`
command will fail just after the gem is created causing confusion to the
users. This change was a bug fix to correctly validate gemspecs.
When an exception is raised, those Action View rendering logs are just
noise for the end developer. I recently silenced those from Web Console,
as we do use Action View rendering in it as well. It used created a half
a screen of rendering logs. I think we can save those in this recent
push for cleaner development logs.
Now, the silencing is a bit hacky and we have a bunch of it now, so we
can also invest in turning off the logs directly from Action View
objects instead of silencing off the logging stream.
`create_table_info_cache` is used for sharing `create_table_info` both
`table_options` and `foreign_keys`. But `foreign_keys` no longer uses
`create_table_info_cache` by #25307. No need caching anymore.
When running tests with `--enable-frozen-string-literal` or
`# frozen_string_literal: true`, it's currently attempted to mutate the path
string in order to append the format, causing a `RuntimeError`.
```ruby
get '/posts', as: :json
```
```
RuntimeError:
can't modify frozen String
```
This commit fixes the problem by replacing the mutation with a concatenation,
returning a new string.
If you had a foreign key set and then decided to add `on_delete:
:cascade` later in another migration that migration would run but
wouldn't refresh the schema dump.
The reason for this was because `create_table_info` caches the statement
and sets it to be the same as the original declaration for the foreign
key (without the `on_delete: :cascade`.
PR #25307 ended up fixing this bug because it removes the check for
`create_table_info` and relies on reading from `information_schema`. The
fix however was intended to patch another bug. The reason this fixes the
issue is we're no longer parsing the regex from the cached
`create_table_info`.
This regression test is to ensure that the issue does not return if we
for some reason go back to using `create_table_info` to set the foreign
keys.
Note: this commit looks super weird becuase git. I'm moving the entire
NPM section to the part where we actually push the gems/npm package for
the reasons below. That's not how the git diff looks though.
When we release Rails we run `rake prep_release` which calls
`update_versions`. This was updating the NPM version as well. But when we
would later run `rake install` to test the installed gem
`update_versions` gets called again which causes the install to fail
because NPM sees the version is the same as the last run and refuses to
continue. If you forget to stash this will then cause the push to
RubyGems to fail because `update_versions` is called again and then NPM
will not continue because it thinks the version hasn't been changed even
though it has.
The correct solution would be to not update the NPM verion if it matches
the version already in the file but after an hour I could not find a
simple way to use NPM to read the current version. Honestly that's not
the best way to do it either because say you forget to update something
else and then the script thinks it's already been updated.
With that in mind I think the best solution is to not update the NPM
version until right before we are going to push to NPM because then that
won't cause the push to RubyGems to fail.
