Day 16 - Audit your dependencies

Crack open your Gemfile, package.json,, 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.

Symfony composer.json :white_check_mark:
package.json :white_check_mark:

I just recently had to redo my package.json because the latest web-ext package, to easily debug Firefox Web Extensions, required a node and npm update and it broke my complete gulp setup after running perfectly fine for 14 months.

Never change a running system:roll_eyes::speak_no_evil:

Moved one dependancy from prod to dev section in my composer.json file. The package.json stays untouched.
Still a good thing to check.

I regularly run bundle update then I run my test suite to see if all tests pass. If so I commit.
Recently I upgraded to ruby 2.5.0 without any warnings.
I recently read a blog post about gem dependencies and how they can drag you down.
I remove faraday and more after that.

1 Like

I regularly update my dependencies carefully, not only by doing bundle update but also by double-checking changelogs for the most mission-critical ones. Even if there are not major updates, I issue a PR stating which updates to which dependencies were made. It’s useful to have insight on regressions.

For those using Ruby, I suggest using something like Gemnasium or Deppbot to keep track of your dependencies (and update them automatically, if you’re confident enough).

1 Like

CodeClimate has been after us to re-order our dependencies in alphabetical order. Now was a good time to appease the Linter Overlords. :v:t4:

There are no dependencies on my project (embedded C project). So, I’ve used the time to look into packaging some python scripts I want to distribute…

1 Like

A careful look through our Buildroot defconfig turned up around a dozen packages which we don’t need to build.

Took this opportunity mainly to improve the annotations in my Gemfile, and also spotted an unused gem in the test group in the process.

One thing I like about Gemfile vs. package.json is that you can add comments to explain why each thing is there and what it’s for. For some weirdly-named gems, I would have to look up what it is every time I see it, so adding comments to remind myself of what each gem is for and where, in broad strokes, it fits into the application… that saves me lots of time. For example, anybody know without looking it up what ‘redcarpet’ does?

I was hoping to finally appease the (very helpful!) GitHub security warnings we’ve been getting, but ended up going way over the 20 minutes and still have some broken tests. This is definitely one I need to finish.

We usually use Codeclimate to help out with this, but I used bundler audit with the updated audit DB (bundle audit update) and found and fixed a new vulnerability in one of the gems we use :+1:

1 Like

I managed to remove the deprecated gem travis-lint, one that doesn’t have to part of the app dependencies awesome_print and moved another one to the production group of the Gemfile, rails_12factor.

I also identified few other gems that should also be either moved from their group or removed. That’s what I call a successful 20min!

You guys can comment in the PR, I’d love some feedback

I found this dependency-checker for node.