I removed some old gems from a Gemfile, then I ran derailed bundle:mem and realized, the largest gem in the bundle was ActionMailbox, an engine that would’ve been better off as a standalone gem. It took almost 1/3 of the whole memory footprint!
Spent a couple of hours trying to make sense out of our Gemfile
Found that rspec was unconditionally required in development mode.
Dropped some clearly unused gems and flagged two that we do not use anymore, but there is code lying around that depends on them - added tickets to review these parts.
Meta. Across 21 projects we had 5 different ways of making xls files.
Mostly caxlsx/to_spreadhseet, but also to_xls, spreadsheet (independently of the dependency of to_spreadsheet), and roo.
Part of my goals is to have some consistency across all the projects. So I’ve identified to_xls, spreadsheet (on its own), and roo as the outliers that can be replaced with either caxlsx or to_spreadsheet.
5 ways getting reduced down to 2 ways is a good step.
I took one of few public packages I have: ttr.aws.s3.utils and immediately found configparser which is obsolete as is already part of stdlib.
When trying to test how things are working now I found, there is another issue (broken namespace packages) which will require more time to fix.
So I filed these two issues to fix it later on.
One possible solution would be rewriting the tool to use poetry which is excellent in tracking dependencies dealing with dependency tree (not flat list of resulting dependencies). For this reason it is very easy to remove some obsolete dependency incl. all secondary packages being there just because of that removed one.
dependabot has made it quite good to keep track of how outdated your dependencies are or to keep them up to date. slimming them down I’m also big fan of but at least with legacy code it’s most often a bit more work to simply do it on the side.
Good one! Composer gave me some warnings about outdated packages. One of them I could completely remove. Another I could replace with a non-abandoned drop-in replacement and a third would require to upgrade the entire test framework so I made a card on the issue tracker for another day. I also learned some more abilities about my package manager, like composer why phpunit/php-token-stream to discover dependencies on a package.
Went through a project that we kicked off recently. Already showed signs of changing technical decisions - things that had been added to test a solution, but the package had not been removed, etc. Helpful exercise.
Another thing to audit is if you have any forked dependencies of active gems. For example we have a forked dependency for image_optim. Normally we try to be good open source citizens, but some times it can be time consuming to merge a PR in and it may be necessary to create a temporary fork in order to have access to a feature or bug fix that you need.
Many months ago I did a gem audit and noticed that our fork of image_optim was drifting from the actual image_optim repo because it was still active and being maintained on a regular basis. I then worked on a PR to kick off the conversation to get our changes merged in. It’s taken awhile, but we finally got the changes in or fork merged in
So now with some minor changes to our code base we can remove our fork and go back to using the actual image_optim gem. We are about to cut a new release of Discourse, so I need to wait a day or two to make this change.