Up to this point, update-interactive has only displayed gems that can be updated.
However, there may be gems in a project that are outdated, yet cannot be updated. It is important for a developer to know this. Otherwise they could be dutifully updating their project regularly with update-interactive yet still be out of date.
The typical example is Rails, which is usually declared like this:
gem "rails", "~> 7.0.8"
If the lock file already has Rails 7.0.8.4 installed (i.e. the latest patch in the 7.0 series), then rails can no longer be updated. As a result, rails will not be listed in the gems to update, according to update-interactive.
In this scenario we colloquially say that Rails is being "held back". That is, the ~> version pin the Gemfile is preventing it from being updated to the latest version, which as of this writing is 7.2.0.
Solution
This PR adds the concept of "withheld gems" to update-interactive. We now scan the Gemfile for gems that have version requirements (i.e. "pins") and make an additional call to bundle outdated to see if there are newer versions for these.
If so, an additional section is displayed: "The following gems are being held back and cannot be updated."
This is a new table that shows the requirement (e.g. "~> 7.0.8") in addition to the changelog url, etc. Highlighting based on semver and security vulnerabilities is also performed.
Due to the additional call to bundle outdated, this makes the CLI somewhat slower than it was before this change. (That said, the additional call is made only when necessary. E.g. it is skipped when there are no Gemfile pins.)
In this screenshot, note how sqlite3 is shown as being "held back":
Problem
Up to this point,
update-interactivehas only displayed gems that can be updated.However, there may be gems in a project that are outdated, yet cannot be updated. It is important for a developer to know this. Otherwise they could be dutifully updating their project regularly with
update-interactiveyet still be out of date.The typical example is Rails, which is usually declared like this:
If the lock file already has Rails 7.0.8.4 installed (i.e. the latest patch in the 7.0 series), then
railscan no longer be updated. As a result,railswill not be listed in the gems to update, according toupdate-interactive.In this scenario we colloquially say that Rails is being "held back". That is, the
~>version pin the Gemfile is preventing it from being updated to the latest version, which as of this writing is 7.2.0.Solution
This PR adds the concept of "withheld gems" to
update-interactive. We now scan the Gemfile for gems that have version requirements (i.e. "pins") and make an additional call tobundle outdatedto see if there are newer versions for these.If so, an additional section is displayed: "The following gems are being held back and cannot be updated."
This is a new table that shows the requirement (e.g. "~> 7.0.8") in addition to the changelog url, etc. Highlighting based on semver and security vulnerabilities is also performed.
Due to the additional call to
bundle outdated, this makes the CLI somewhat slower than it was before this change. (That said, the additional call is made only when necessary. E.g. it is skipped when there are no Gemfile pins.)In this screenshot, note how
sqlite3is shown as being "held back":TODO