Florian Munz, Co-Founder at Depfu

Are you sharing code between your different projects? Depfu now supports all package registries you might use for your own private shared libraries.

Let’s have a look at how that works in detail:

Detection

Depfu auto-detects any registries you are using that are not the official rubygems.org or npmjs.org. The way this works depends on the language:

In Ruby the additional sources are part of your Gemfile, usually like this:

source 'https://rubygems.org'

gem 'rake'

# all my private gems:
source 'https://gem.fury.io/depfu/' do
  gem 'myprivate_gem', '~> 3.7'
end

Here we would detect that you’re using another gem source and check if we can access it or if it needs authentication.

In JavaScript detecting private registries is actually a bit more tricky, since this information is not part of the package.json or lockfile. We rely on a checked-in .npmrc to do the detection. In this file you can tell npm how to authenticate and which package scopes should live in what registry:

//registry.npmjs.org/:_authToken=${NPM_TOKEN}
@flowbyte:registry=https://external-registry

From this example we would know that the scoped @flowbyte packages live in the “external-registry” and there might be additional private packages on npmjs.org, which Depfu will find later.

Authentication

In most cases these external registries need some kind of authentication, since you want to use them for sharing private code as opposed to code that could be open-source.

That means that we rely on you to also give us access to these external sources. This is the same as giving your CI-system access in order to install the packages and run your tests. Most external sources have a way of only giving read access, which is all we need for Depfu.

After we detect an external source, we ask you to tell us how to authenticate. That could be username:password or usually some kind of token. You can enter this information in the settings for your organization:

In case of Bundler we actually need the auth information to continue sending you updates at all, even for public gems. Bundler constructs a full dependency tree to run any update and your private gems are part of that as well. Apart from monkey-patching Bundler heavily, which we obviously want to avoid, there is no way for us to ignore your private gems while sending you updates for public gems.

Polling and Updates

After we have access to an external source, we start polling it regularly and will send you updates via pull requests the exact same way as for your public dependencies.

We intentionally have some delay in the system, so don’t be surprised if the pull requests don’t come in right after you released a new version of your private library.

Push vs Pull

Apart from helping you to keep all your dependencies up-to-date, we think moving your own private libraries from a pull to a push method is a big improvement. If you ever had to do the checkout/update/push-dance to update a shared library in a lot of projects at the same time, you’ll realize how much nicer the push model is.

As always, if you have any questions, ideas or feedback about this: Let us know on Twitter or via email.