Private package registries

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

For Ruby we support all external sources. That could be self-hosted gem servers, like Geminabox and Gemstash or SaaS registries like Gemfury and packagecloud. Also public 3rd party sources like Rails Assets and private sources like Sidekiq Pro/Enterprise are supported.
For JavaScript we support private packages on npmjs.org and dedicated external registries, be it the above-mentioned SaaS registries or self-hosted like your own NPM registry and tools like Verdaccio.

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<br>

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<br>

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.