This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Message originally sent by slack user U78F0G7XH32
Hi! I have a question for anyone who has broken a monolith up into gems. Do you do anything to ensure that those gems are tested with the same versions of third party gems as the application runs with?
At Root, we haven’t done anything special - most of our Rails-provided dependencies don’t specify a version at all, but otherwise we provide liberal version strings where we can. This isn’t really much different than if we were publishing gems for consumption by others, though. The Gemfile.lock is the final say since that’s what’s installed before running our tests in each gem.
This has been one of the biggest pain point of using gems as components. I recently discovered a bug related to PDF form filling (think taxes) where a change in Ruby’s round led to the potential of displaying a dollar amount not as 1234.00 as 12.34.
It doesn’t happen often, but it can bite you… You have three options:
• ignore the problem
• lock down all versions you care about to an exact version in every gem (then bundler won’t let you create incompatible dependencies)
• keep all versions liberal and run the component’s tests against a matrix of all dependency versions that you expect to observe in production
What we are doing is dynamically generating our Gemfiles by parsing the root Gemfile and Gemfile.lock.
In the dynamic Gemfile we specify exact versions, so they stay in sync with whatever is in the root application Gemfile.lock. Then we gitignore the Gemfile.lock files for our gems, so that we end up with only one place in our repo that specifies the exact versions to use.
It works and its nice because there is a single source of truth for versions, but really it involves a bit too much digging around in Bundler’s internals.