I think this would be valuable to add per our team conversation this morning about gem lists being hard to maintain. Maybe we could add a section describing what to look for when evaluating gems to use on a project.
Here's roughly what I consider when looking at a gem's GitHub repo, in no particular order:
- When was the gem last updated?
- How many contributors does the gem have? How many commits does it have? Open issues? PRs?
- Read through the open issues and look for red flags like unfixed bugs, issues requiring a rework of the system, or issues that haven’t been addressed in a long time or that were never addressed
- Is the repository stable? Does it release major, stable releases or is it still in an early alpha version with constant updates?
- If CI is implemented, do the builds for the most recent version pass?
- What versions of Ruby/Rails does the gem support? What versions does it not support?
- Does the gem contain all the features you need it to? If not, what will I need to account for that the gem doesn’t cover?
- Does the gem rely on external dependencies (e.g. wicked_pdf relies on wkhtmltopdf)? If so, how will I account for external dependencies in the deploy process?
- Overall: Is using the gem going to be more efficient and maintainable than developing a custom solution myself? Do I have to change my design to work around the limitations or design of the gem? Will the version I'm using be maintained and stable for a reasonable length of time (depends on project)?
I think this would be valuable to add per our team conversation this morning about gem lists being hard to maintain. Maybe we could add a section describing what to look for when evaluating gems to use on a project.
Here's roughly what I consider when looking at a gem's GitHub repo, in no particular order: