If you’re developing software solutions, there’s a good chance that you’ll have to rely on external code dependencies. These dependencies can save time, which will ultimately save money and keep your clients satisfied. They can also introduce hefty risks which can undermine the very reason for their inclusion in your project. Managing these dependencies goes a long way to securing the efficiency and timeliness of your deliverables. Here’s how we manage our code dependencies.

Define a Selection Criteria for Your Dependencies

It’s important to make sure your code is vetted, especially if you’re introducing code from an outside source. As convenient as package managers are, there’s no guarantee that all of the packages they serve have been vetted. It’s up to the open-source community to do its due diligence in maintaining these solutions. Thankfully, package managers like NPM provide statistics to help you judge the usefulness of different dependencies. These statistics can also be gleaned from hosts like GitHub. Here are some questions you may want to include in your selection criteria.

  • Is the dependency being downloaded frequently by other developers?
  • Is the dependency being maintained?
  • Are other packages using this dependency?
  • Is the dependency well documented?
  • Are you compliant with the license of this dependency?

Audit your Dependencies Regularly

Importing dependencies into your project can be a time-saver, but it’s not without its risks. Because these dependencies weren’t created in-house, you end up putting some trust into outside sources. The open-source community can help to vet dependencies and report issues on sites such as, but you shouldn’t depend on them to catch everything, nor should you expect the original publisher(s) to maintain the codebase. Try to get in the habit of auditing the dependency libraries yourself. Following these guidelines can help:

  • Install the latest versions of your dependencies unless your code relies on a version-specific feature
  • Remove any unused/invalid libraries references (the fewer, the better)
  • Check if your package manager CLI has its own auditing operations (for example, npm uses npm audit and npm audit fix)

Being compatible with the license of a dependency is something that is often overlooked by developers. Just because a library is readily available and popular, it doesn’t mean that you can use it for your purpose. For example, license compatibility between a copyleft license and another license is often only one-way compatibility, making the copyleft license (GPL, and most other copyleft licenses) incompatible with proprietary commercial licenses, as well as with many non-proprietary licenses. License incompatibilityies may not seem like an issue, but come up in the least convenient times such as when they are about to get released, deployed, or incubated by organizations such as Apache, Location Tech, Eclipse, etc.

Vendor your Code Dependencies

When managing your code dependencies, you’ll want to ensure they remain in their current stable state. If your 3rd party dependencies pass your audit, the next step would be to vendor these dependencies to lock them in their current state and make them accessible with or without the remote package. Vendoring your dependencies essentially saves a copy of the 3rd party dependencies into your version control system. This allows you to build your project without having to rely on remote package managers to spin it up. This opens the door to offline development and eliminates the need for the host to have to tap into a remote package manager.


Hopefully, this has given you some good insight into how to better manage dependencies in your projects. Keep in mind that managing risk is a balancing act. The time you invest in addressing risks needs to be worth it otherwise you’ll find yourself in pursuit of perfection at the cost of valuable time. Make it work and make it worth it.

Interested in working together?

We’d love to discuss how we can work together.