No specific motivation here, no awareness of security issues; this is just an important gem to be unusually on top of, to prevent XSS attacks.
We were previously on 6.1.3, the previous release, and the only changes were Ruby compatibility and additionally supported CSS properties (which we don't use). But this just keeps us more easily plugged into potentially important fixes down the line.
This is a Ruby LSP that I no longer use, because I'm on RubyMine full-time.
My immediate motivation for this change is that solargraph's eventual dependency on the `parser` gem triggers warnings on all Rails commands, hinting that it doesn't support the *exact* Ruby version we use.
This could potentially be resolved by upgrading Solargraph or some of its dependencies, but since I'm not using it anyway, may as well just remove!
We discovered a previous string encoding bug fix that was causing crashes for some items, was casuing *other* items to get reencoded incorrectly.
In this change, we make the reencoding conditional, only if parsing as UTF-8 is failing.
We also include a temporary repair script, to run in production then delete—but held here in git history for posterity.
It says "This item is part of a deluxe paint brush set.", with a period instead of exclamation mark.
There are also a couple cases where the paint brush item additionally has an "inspired by" credit after the first sentence. Rather than get picky about the pattern, we expand the `pb?` method to just check for the sentence as a substring, like the DB filter logic for `Item.is_pb` already does.
We run DTI on a few different architectures in practice, and the `vendor/cache` directory can be a bit confusing to manage when switching dev machines.
In this change, we add all our common dev machine platforms to the Gemfile.lock, so precompiled gems for all of them are cached, granting us resilience against the possibility of Rubygems going down, and speeding up deploys & installation.
The connection_pool gem changed their API, which caused a breakage in our react-rails gem.
It turns out though, we're not actually using react-rails anymore. It's primarily for React server-side rendering, which we don't do. Our React code is bundled as normal Javascript via our usual asset pipeline.
So, to resolve the gem incompatibility, we remove react-rails altogether. Neat!
