Jan Krutisch, Co-Founder at Depfu

Packages, especially in node/JavaScript land, have been used to modularize software for some time now. The monorepo as a structure that defines a flurry of packages under a common namespace and released with the same version number at the same time has become somewhat popular in the last few years, with popular packages such as Babel leaning heavily into that.

We have, if a bit crudely, supported these monorepo-packages for quite some time. In the beginning via Greenkeeper’s monorepo definitions, then, after Greenkeeper became part of Snyk and the list was no longer maintained, with a private list that we updated whenever a client mentioned something missing.

We’ve decided to finally publish our own lists to depfu/package-groups on Github (for both npm and Bundler) and use these as sources from now on. So if you find some group of gems or npm packages that are released in lockstep and with identical version numbers (both prerequisites for our system to pick these up), you can now just open up a pull request on that repo and your list should end up in Depfu relatively soon.

Proprietary private package parcels

That’s all well and good but does not work for private packages within a proprietary software project. For a while now, we’ve been chipping away at a solution to make that possible and we’re happy to announce that you can now add your own package groups by defining them in the Depfu config file.

There are a couple of things to note:

  • Right now this is organized per repository. We’ve built it that way because we wanted to use the config file for this and we currently don’t have org level config files.
  • Again, the prerequisites are that the packages in that list are released in lockstep with identical version numbers.
  • We obviously need read access to your private package repository to be able to update these. This should already be the case and if not, Depfu will ask you for access on the dashboard for the repo.
  • Nothing stops you from adding publicly available packages to the lists but a) be aware that our public lists will always have precedence and b) that we would rather see you submitting a PR for our public lists if we’ve missed something.
  • It currently only works for npm packages and Rubygems. We haven’t been asked about this for PHP or Elixir, but if you are missing this functionality, let us know.

An example

Here’s a fictional example of a package group definition for npm in .depfu.yml:

    npm:
      package_groups:
        depfu_npm_support:
        - "@depfu/npm-support-main"
        - "@depfu/npm-support-parser"
        - "@depfu/npm-support-updater"

The package group name is more or less irrelevant for npm but will be used in branch names, PR titles and such. For Bundler, the name needs to be the name of the “main” package of the group (think rails and all the active*/action* gems).

Please note that for freshly added repos (freshly added to Depfu, that is), the first grouped updates for private groups may take a little longer to appear. Mainly because we’ll need to ask you for credentials to the package registry and only after that we can figure out if updates are available.

Please use and give feedback!

This change should make handling of private packages, especially of the monorepo variety much easier and can not only reduce the amount of pull requests but also the amount of churn due to incomplete updates.

Please, as always, let us know how this works for you at hi@depfu.com.