Crack open your Gemfile, package.json, setup.py, or whatever file your language/dependency manager uses.
Give it a slow scan. Ask yourself:
Do you still need everything in there?
Does anything need to be updated?
Can you reduce a production dependency to a development/test one?
Rubyists: maybe run bundler-audit to automatically check for gems with known vulnerabilites.
Is your file nicely laid out and sorted alphabetically? Should it be?
I removed active_link_to from our Gemfile as it was only used a couple times in some admin page. Checking request.path or Railsā current_page? was good enough.
Got our project upgraded to RxSwift 6 and finally got access to the new .withUnretained(self) operator 
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!
TOP: 121.1445 MiB
rails/all: 65.6484 MiB
action_mailbox/engine: 40.6172 MiB
action_mailbox: 40.6172 MiB
The solution, of course, is to require only the engines/railties you need, and after some googling I came up with a reddit entry that explained the same issue. 40MB shaved off like that!
Thanks!
Moved a single dep to dev deps, and found a handful of dependencies that could be deleted (because they were included transiently anyway or not in use anymore).
I got rid of the gems that are no longer in use: overcommit, guard-rspec, hashie, also removed zeitwerk from Gemfile because itās required by default. Good one!
yarn audit did flag one critical issue which got solved by updating the version of one dependency 
Small things count!
Went through and fixed two dependency update PRs from renovate bot (GitHub - renovatebot/renovate: Universal dependency update tool that fits into your workflows.) that needed a bit of extra attention to get the builds passing. It has been making dependency updates much easier when we donāt have dependabot on Bitbucket.
Learned about derailed thanks to @julianrubisch
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.
Thanks for the tips! Especially for GitHub - schneems/derailed_benchmarks: Go faster, off the Rails - Benchmarks for your whole Rails app
Iāve been doing scheduled security audits on dependencies for years, but took the time today to add a yarn audit step to a Rails app that picked up some new JS functionality recently.
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.
Managed to slim down some dependencies as I used minimal functionalities of it which I could easily create myself.
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.
I found a deprecated package (for dealing with ātimezonesā) that could be removed entirely. Also ran npm audit. Great!
Removed sequel which we previously used instead of active_record in a microservice we integrated in our āmajesticā monolith. Long overdue, felt good!