Day 16 - Audit your dependencies

1

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?

Give it 20 minutes. Celebrate your continued focus on code quality. Maybe post on the forum.

2

I tend to be the one on my team that keeps our Gemfile organised and up to date already. I’ve seen the pains of upgrading after things have been outdated for so long.

We don’t keep things in alphabetical order, but we do group gems by there purpose such as API, Authentication & Authorisation, Security, Scheduling, PDF Handlers, File parsers, File management, Third Party Services, a few others and of course, no list is complete without ‘Other’…

There are several gems I’d vote to remove completely, but there is always one person who loves them. We use annotate. Annotate can die a horrible, fiery death. (Sorry!)

1 Like
3

There are no real dependencies in PL/SQL. But there are objects which are outdated/not used anymore and I identified and dropped some of them.
This might come in handy:

select * from user_objects uo
where 
  object_type in ('PACKAGE', 'PROCEDURE', 'FUNCTION')
  and not exists (
    select 1 from all_dependencies dep 
    where dep.referenced_name = uo.object_name and dep.referenced_owner = 'MySchema')
  )
2 Likes
4

Speaking of Gemfiles, when I started the current codebase we’re working on I decided to annotate each Gem as it was added. 4 years later it’s been helpful when doing a task like this. Here is a sample:

image
image.png1376×516 50.3 KB

Out of curiosity, where do people stand on the “specify the version in the Gemfile” camp these days? Is A Healthy Bundle still the recommendation?