On Forking and Republishing a Gem
Scroll DownHow to deal with projects with dependencies on unmaintained rubygem? Most of the time just forking and making necessary changes will do the trick. In our case we had to republish the gem in a different name.
We have a few of our projects that uses our own rubygem which also depends on Her gem. Her is a gem that makes REST request look like Activerecord calls. We use Her to standardize API calls within our microservices. It was great. It reduced the amount of code we have to write dealing with CRUD between our applications.
The problem is, it stopped working when we updated our Ruby on Rails applications to Rails 7 and Ruby 3. Most of the issue is due to Faraday versions of other gems we are using has been updated to Faraday version 2.x while Her is stuck on Faraday version 1.x. Our applications won't boot due to version incompatibilities. Checking the Her Github repository leaves us hopeless as it hasn't been updated for years even after numerous request in the issue section.
We can always fork the project, do the fixes and reference our fork using the git url in our Gemfile. But this only works if our application depends directly on Her. It is another gem of ours that depends on Her. We can't use git urls in gemspecs. This forces use to publish our fork in a different name as Restorm.
We would have removed Her altogether if not for multiple projects that uses it. Rewriting parts that uses Her is doable but doing so for multiple projects and making sure to rewrite the tests is a whole lot more effort. Some of those projects are owned by different teams which might not have the same goals inlined.
N.B. - Technically, we didn't fork Her directly. It was a fork of a fork that already have most of the fixes we need.
View Comments