activestorage-hotcell-client requires mini_magick at load even when only the Vips transformer is configured

[flavorjones]

activestorage-hotcell-client loads every transformer at require time. lib/active_storage/hot_cell/client.rb:9 requires transformers/image/magick, which subclasses ActiveStorage::Transformers::ImageMagick, and Rails' active_storage/transformers/image_magick.rb:3 requires image_processing/mini_magick unconditionally. With image_processing 2.x, where mini_magick is no longer a dependency, that require raises:

LoadError: ImageProcessing::MiniMagick requires the mini_magick gem. Please add `gem "mini_magick", "~> 5.0"` to your Gemfile.

So an application that only configures the Vips transformer, and never installs mini_magick, fails to boot as soon as it requires active_storage/hot_cell/client. Fizzy hit this on basecamp/fizzy#3056, which bumped image_processing 1.14 → 2.0.3; the chain is saas/lib/fizzy/saas/cell.rb:6 → client.rb:9 → transformers/image/magick.rb:4 → Rails image_magick.rb:3 → image_processing/mini_magick.rb:5.

Rails guards the Vips side: active_storage/vips rescues the LoadError and sets ActiveStorage::VIPS_AVAILABLE = false. It does not guard the ImageMagick side, and neither does this gem, so the gem effectively requires both backends' gems while the application picks one.

Fizzy's workaround is basecamp/fizzy#3106: declare mini_magick in Gemfile.saas with require: false, purely so the require can succeed.

Proposal: load the ImageMagick transformer (and the ImageMagick analyzer, which is fine today but shares the fate) lazily, with autoload under ActiveStorage::HotCell::Client::Transformers::Image or an Image::Magick Kernel#require inside a begin/rescue LoadError that leaves the constant undefined. An application then pays for the backend it configures, and the gemspec's silence on mini_magick and ruby-vips becomes accurate rather than accidental.

🤖 Generated with Claude Code