Depfu

Package groups, but better

Wed, 03 Dec 2025 00:00:00 +0000

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.

Previously, on Depfu

Wed, 23 Apr 2025 00:00:00 +0000

It’s been a while! We kinda forgot to post here (for reasons) but let’s get into that again with a recap of what happened in the previous season of Depfu 🦈.

So, let’s take a look at a few things we’ve released.

Behind the scenes

A lot of the ongoing work at Depfu is simply catching up with new versions of package managers. Sometimes that’s a quick thing and sometimes we need to put in a lot of effort to adapt to the changes or to support features of that new version. Last year we’ve added support for Bundler 2.6, pnpm 9 and Yarn 4 with corepack.

We’ve also re-architected how dependency updates get executed, which was a big and important refactoring for us, but didn’t have any visible effects for you.

Customizable PR titles

This one is pretty self-explanatory and also has been available for quite some time: you can now customize the title for the pull requests Depfu creates, similar to the commit message.

Gitlab bot user as a service account

If you’re using Depfu on a private repo on Gitlab we have good news for you: We now support service accounts instead of our dedicated @depfu-bot user.

This new approach is not quite as nice, but has one major upside: service accounts are non-billable users for Gitlab, which means Depfu won’t be using a seat on your Gitlab plan.

We’re still working out a few edge cases and will have a dedicated post on this soon, but if you’re interested in giving it a try, please let us know.

Engine release tweaks

We’ve heard from you that engine releases (so new versions of Ruby, nodejs, etc.) often get stuck waiting for upstream providers like Heroku, Docker and similar to make the new version available. So now we simply wait for 7 days before we send you the PR for a new version.

We also made it possible to choose which major line you want to upgrade to from our dashboard. For cases where you want to update step by step or to a specific version.

Package aliases for JS

We finally detect and support aliases in package.json. This was mainly driven by requests to support the jsr.io package repository in non-deno environments. But it works in all cases where you alias a npm package.

{
  "dependencies": {
    "npm": "10.3.0",
    "npm6": "npm:npm@6.14.13",
    "@std/path": "npm:@jsr/std__path@^1.0.3"
  }  
}

And even more small tweaks

Of course there are always bug fixes, really tiny things and ease of use improvements. A few worth mentioning are:

✨ You can now abort an automerge with @depfu cancel merge
✨ We remember the last selected org in the dashboard
✨ Github: Support for merge queues
✨ Bundler: Handle the new ruby file: '.ruby-version' syntax

Feedback

We’re always looking for small (and big) things that make your life with Depfu easier, smoother and calmer. So please don’t hold back on any feedback, we’re listening on Mastodon and via email.

Support for import maps in Rails

Wed, 08 Nov 2023 00:00:00 +0000

If you’ve followed the recent Rails releases you’ll probably not have missed the push towards no-bundling and import maps as the preferred way to bring in external JavaScript libraries.

Import maps let you import JavaScript modules using logical names that map to versioned/digested files – directly from the browser. The README has a good overview if you’re not familiar with how it works.

Import maps are a general concept, but Rails added a gem to make them work nicely with the new asset pipeline, which is what we’re supporting now in Depfu.

Compared to pnpm and other package managers we actually didn’t get that many requests for import maps. But since we initially built Depfu for the Rails ecosystem, we felt a responsibility to support all the possible ways to bring in JavaScript.

How it works

Importmap-rails is not a real package manager, nor does it pretend to be. It’s more like a pragmatic next step after realizing that putting all libraries as script tags into your application layout is maybe not that great of an idea.

You get a config file called config/importmap.rb that lists all the npm packages you are using. You can reference them as local, vendored files or more commonly as URLs pointing to CDNs that specialize in providing JS dependencies for import maps, like JSPM.org and jsDelivr.

# Pin npm packages by running ./bin/importmap

# referencing a CDN
pin "react", to: "https://un5q08ug2k7veu4khhq0.julianrbryant.com/npm:react@17.0.2/index.js"
pin "object-assign", to: "https://un5q08ug2k7veu4khhq0.julianrbryant.com/npm:object-assign@4.1.1/index.js"

# or referencing vendored files
pin "react" # @17.0.2
pin "object-assign" # @4.1.1

In both cases it also includes a version, which is where Depfu comes in: Since there is always a npm package behind every import map URL, we can hook into our existing npm support. Depfu will send you PRs for every new version, either as an individual update or as a grouped update bundling several dependencies together. And of course our patented* reasonable up-to-date strategy is also supported.

* not really

A few caveats

Since the import map support in Rails is not a full blown package manager there are a few caveats you should be aware of:

The biggest one is that importmap-rails doesn’t differentiate between direct and indirect dependencies. It knows when to bring in subdependencies of the direct dependency you are adding, but it’s simply adding them to your importmap.rb file. So when you’re later trying to update that subdependency you don’t know which parent dependency it relates to. Similarly, when you’re removing a direct dependency you don’t know which subdependencies you can remove at the same time. And it gets even messier when multiple dependencies rely on the same indirect dependency.
There are no version specs, only pinned versions (so no twiddle wakka or caret operator). This is not a problem for Depfu per se, but means you can’t indicate to us that you don’t want to update to the next major React version just yet, but minor and patch versions would be welcomed.

Give it a try

We didn’t automatically enable this for existing repos, so please find the “+ Add” button in the repo dashboard in Depfu and it will allow you to activate it yourself.

We have a few ideas to improve upon these limitations, but for this first release we’re behaving exactly like importmap-rails and we’ll see what the biggest pain points are. Please give it a try and let us know any problems or ideas you have!

Depfu now supports pnpm

Tue, 07 Nov 2023 00:00:00 +0000

tldr: Depfu launched a beta version of pnpm support that should work for most people using pnpm. If you find any issues, please let us know.

We’ve had requests to support pnpm for a long time and we finally got around to implementing it. Deciding to support a new package manager, even if adjacent to existing implementations is always tricky. On one hand, you would think that it instantly grows our audience, at least when it is a popular choice. On the other hand, every package manager is a new breeding ground for bugs and their gentler sisters, edge cases.

For us, one deciding factor is the adoption outside of open source projects. While having Depfu available for free for open source projects is great marketing and also a service we love to provide, it is only from private projects that we generate revenue that allows us to provide the free service.

For pnpm, to us it looks like it now has enough adoption that we can justify supporting it.

Pnpm certainly is an interesting package manager. It makes some technological choices that make it very enjoyable to use as a developer. Most people would probably praise its speed and it certainly is impressive, especially in contrast to npm itself.

Supporting pnpm on Depfu was not without its challenges, though.

A wild yaml file appears

The most interesting one from a tech perspective is the lockfile format. It is saved as YAML, which is somewhat standardized, but there are lots of different parsers and generators out there and they all treat YAML slightly different. Nevertheless, I decided that I didn’t want to build a process that would need to run the actual pnpm yaml parser, but instead just use Ruby’s psych library.

Unfortunately, in the mission to (I think) both reduce file size and make git merges as easy as possible, pnpm made some, let’s say, edgy choices on how to generate their lockfile. I’m not complaining too much here, because you would normally assume that pnpm is the sole distributor and consumer of these files. Unless you aren’t. Turns out that you actually need a very modern version of libyaml, the underlying C-library of psych, to be able to parse all constructs that pnpm uses to save space. This leads to some interesting challenges in making sure psych can use the latest libyaml version on all platforms Depfu code is run on. We’ve been maintaining our own docker base image for quite some time now and this was a good reminder why.

When caches don’t work

The next challenge sounds a bit counter intuitive but one of the things that makes it quite problematic to run pnpm is its aggressive caching strategy using the content store. This is the core thing that makes pnpm fast, because it only creates symlinks instead of downloading or copying files.

The way that pnpm has implemented this means that it is really fast in day to day local use, but actually quite slow when used with a cold cache or rather an empty content store. And for safety reasons, we cannot keep the content store between runs. The scenario of leaking a private package of a customer is rather theoretical but it’s one of the things you want to prevent to even happen theoretically.

Another by-product of this aggressive caching strategy is that pnpm never seems to use the npm package API to look up anything else but the download URLs, so it actually downloads all packages while resolving the dependency tree. There is a command line switch --lockfile-only that, in theory, should only operate on the lockfile (and npm, for example, only downloads packages for which the API doesn’t work like git dependencies), but in practice it only doesn’t link the packages into the node_modules folder.

These two issues combined mean that unfortunately pnpm is a bit of a pain to operate as it is not only slow but also needs quite a bit of system resources.

Technically, these are valid tradeoffs to be made. For a package manager, providing a better developer experience will always be more important than optimizing for this one weird use case. There is, though, something to be said for tools that can do both and in that respect, pnpm has a long ways to go at this point.

In the upcoming weeks, while we iron out the last kinks in the pnpm implementation we’ll figure out how to properly feed this back into the pnpm development process.

Dependency patching. The good, the bad and the ugly.

I need to mention one thing in the end that seems to be very popular with the pnpm crowd that I find quite troubling and that is built in dependency patching.

First introduced in yarn 2, I think, but also available in other ecosystems (for example, composer has a plugin for that), pnpm also supports a workflow for directly patching dependencies.

First of all: I know why this feature exists. It’s often not possible to quickly get patches into a package that is broken for you. Been there, done that.

But I think yarn 2/3 and pnpm make it way too easy to quickly patch packages in your dependency tree. And a quick scan over a couple of pnpm based repositories seem to support that point. If you have patches in maybe half of your direct dependencies, it points to something being extremely wrong.

The way I see it (And I realize that this is not necessarily a popular opinion), being able to patch dependencies locally makes it really easy to skip the step of at least trying to get it applied upstream. Providing a patch to an open source project isn’t always fun, it’s not even always possible and it takes time your bosses probably don’t want you to spend on that. Still.

Adding to that, most patches I’ve seen applied in the wild are untested quick hacks. They never actually ran through a CI suite (Apart from maybe being accidentally being tested in a test of your application) and they are stored in a format that is really kind of hard to reason about.

Git dependencies do exist

I fail to see why the alternative to fork the upstream project and then use a git dependency is such a big issue. It gives you a quick way to provide a patch to the upstream project. It allows you to add to their test suite. Your changes exist in the form of proper git commits instead of a patch file in a directory.

Coming back to Depfu and the job we’re trying to do, it doesn’t matter much which solution you’re using, but we’ve built support for git dependencies ages ago.

For patches, our only real solution is to ignore the patched dependencies, which was something we had to add as a new feature to Depfu. The reason is, of course, that patches will often not apply cleanly on a new version of a dependency.

What we’re currently missing is a possibility to show these cases in our dashboard - We’ll add that later. For now, know that if you use pnpm patch, you’re opting out of dependency updates for that dependency until you’re removing the patch.

What works, what doesn’t

In terms of features of pnpm we’re currently not supporting:

We don’t have explicit support for branch lockfiles (And we will ignore any lockfiles not named pnpm-lock.yaml).
We also don’t support plug-and-play in that the resulting modules file will not be part of the pull request.
Last but not least we currently also don’t support .pnpmfile.cjs and probably never will as we can’t really control what’s going on in there.

Building support for pnpm was a bit more involved than we thought and we are interested to see what weird edge cases you all can come up with to keep us busy 😊.

Configure Depfu with config files

Thu, 08 Sep 2022 00:00:00 +0000

tldr: You can now configure the behavior of Depfu by adding a config file to your repo, the docs are here. Finally!

Listening to feature requests from users is a tricky thing. Sure, if a lot of people ask for support of their favorite package manager, eventually it will make sense for us to build it. But as the product management trope goes, people often ask for specific features while actually, they want to solve a specific problem, which is not the same thing. Maybe the feature they asked for is the best solution, but that’s definitely not always the case.

Over the years, people have asked us to support config files as other tools do. For a very long time we’ve been super reluctant to add them, because we felt like a) a well structured UI can explain your options much better and thus reduce misconfiguration and b) having different configs for different branches (in contrast to CI, for example) doesn’t make a ton of sense for Depfu.

Okay then

At this point we think that we might have been wrong about this, or, put differently, it was probably not something we should have resisted for so long. So, yes, you can now add a file to your repos that will configure all the settings (with the exception of privacy sensitive settings like tokens etc.) the moment you push it into the repo or the moment you activate the repo on Depfu.

We’ve decided to make this relatively simple, hopefully not too simple. To add a configuration to a repo, simply create a file called .depfu.yml . Yes, we chose yaml as the configuration language. Our thought here was that even though many people hate yaml for its quirks and its ambiguities, you probably already have a couple of yaml config files in your repo and so you probably have syntax highlighting in your editor, maybe even a linter in place.

The config syntax is very flat, in an attempt to keep both the syntax to learn (or look up) simple but also our parsers. Here’s an example from the documentation:

update_strategy: security

yarn:
  update_strategy: grouped
  grouped_update_schedule: weekly
  grouped_update_start_date: "2022-01-01"
  grouped_update_time: "6:00"

As you can see, you can override settings for specific package managers. Additionally, if you have more than one folder activated from your repo, you can have a global config file and then have specific overrides in the sub folder. This gives you a large amount of flexibility but we implore you to keep this as simple as possible to not confuse yourself (and us).

What happens with the settings UI

We’ve been a bit lazy with this, for now. You can still change settings via the UI (But it will warn you if a config file is present) and it’s simply “last change wins”. So make sure that you and your team agree on one way of doing it and then sticking to it to prevent playing a game of settings ping pong where team members change settings in both places to find out who wins. It’s a fun game, but probably not very productive, all things considered.

The settings page is also the place to look for error messages. If you have a feeling that your config file changes have not been picked up, there will be error messages with hopefully useful error descriptions on that page.

Why use one or the other method

People who have asked us for config files often ask for them because Depfu doesn’t have a concept of organization wide defaults (except for a few settings).

If you want to make sure that all the projects you’re activating in Depfu start off with the same set of defaults, then you now can simply drop one file into each of your repos, which is a much simpler thing (and can be handled via template repos in GitHub) than having to instruct teams to go to the settings page, and list what kind of changes they need to make to each setting. In that sense, it is great for teams that simply have a ton of repos, often create new ones and that will want to enforce a certain set of standard settings for Depfu.

On the other hand, if you just added your first repo to Depfu, the settings page is much easier to understand, we think, and doesn’t need additional documentation, so we feel like there’s no need to use config files just because they are available. The settings UI will not go away.

You can find the full documentation here. Please let us know if you run into any issues or if you miss something.

We hope to ease the pain for bigger teams quite significantly with this change. Sometimes the feature you want is the feature you need.

Support for Yarn 3

Wed, 07 Sep 2022 00:00:00 +0000

We’ve been dancing around supporting Yarn 2 aka Yarn Berry for a while now because adoption seemed not to be there. It looks like that has changed.

We’ve now launched support for Yarn Berry and the important bit here is that we only support v3 and not v2. Yarn 3 has some command line switches specifically designed to support things like Depfu and that allowed us to build a much simpler version of Yarn support than what was possible before. Given that Yarn 3 has no additional drawbacks over Yarn 2, we think that migrating should be not a huge issue for most teams.

Our support for Yarn 3 is not complete, unfortunately:

Depfu will not maintain offline caches for zero install.
We will load patches, but we don’t support updating patched dependencies.
We don’t support constraints right now.
We do honor the vendored version of Yarn and vendored plugins. We do not support any specific plugins beyond simply providing and loading them.

What about zero install?

From the looks of it, this seems to be one of the more desirable features of Yarn Berry. For us, supporting the offline cache that’s the basis for zero install is, unfortunately, at least currently, sitting between “very hard” and “impossible”. Here are some reasons for that:

With Yarn Berry, updating the offline cache is unfortunately not as easy as with other package managers, as Yarn repackages every dependency in a different, probably slightly more efficient format, which means that Yarn actually needs to be involved. For other package managers, we simply download the packages from the registry and sort them into the git branch we’re working on.

Unfortunately, the Git Data API of GitHub, which we use for constructing the commit for an update, has some hard limits of how big a commit can be. We’ve run into this limitation already with Bundler, but given how large changesets for Yarn dependencies can become, we’re pretty sure we’ll run into this limit quite often. Fixing this would mean to completely rewrite the way we’re interacting with GitHub. That would not only be a very big, complicated change, but also would be much more expensive in operations.

A slightly dirty workaround

What we’ve told a couple of clients when we asked them to test Yarn 3 support is to handle this in a CI step that runs after Depfu. This is not a great solution because it messes with Depfu rebases, as we only rebase PRs that are not touched by other people’s (or robots) commits. But it does work and maybe we would even be able to support that with a bit of extra code so that these CI commits can be ignored and we could still run rebases. Let us know if you want us to try that.

Worth the upgrade?

Yarn Berry is a bit of a weird one. The engineering feels very solid and some of the ideas are really quite good. From a personal standpoint, having dealt with it during our implementation and testing phases and having read a lot of documentation, Berry feels a bit over-engineered, though.

I may be totally wrong and it could be that especially for larger teams and more complex setups, all the extra complexity is worth it, but there are a few things that I am really skeptical about. Having a generic plugin interface in a package manager sounds like a great idea, for example, but all I see is a bunch of extra complexity that might come to bite you at the most inconvenient moment in the future.

To me, and I am ready to admit that as a developer on Depfu I may have a unique perspective, package managers should be, as the saying goes, as simple as possible, but not simpler. They should focus on simplicity first and then performance. Yarn Berry errs on the side of trying to enable everything that anyone ever could want from a package manager.

That being said, I am very happy that the Yarn Berry team thought of the robot factories and specifically added options to support automated dependency updating. Integrating Yarn 1 has been quite a challenge and requires some really weird pieces of code.

Given that Yarn 1 is in sort of a “bugfix only” mode by now, I think it makes sense to migrate away from it in the near future. That could mean migrating to Yarn Berry, but of course it could also mean migrating to a current version of npm, since npm by now supports most of the Yarn exclusive features such as workspaces (and we’ve recently updated our npm integration to support them).

Assigning and reviewing PRs

Tue, 08 Jun 2021 00:00:00 +0000

We just shipped a few improvements to how you can assign PRs and request reviews.

The goal was to support all features that were introduced by Github and Gitlab since we last worked on this, which was quite some time ago.

⚠️ We’ll be requesting one additional permission on our Github App in order to make these features possible: read-only access to organization members and teams.

Github

Request reviews from teams

Github allows you to request reviews from individuals and teams. We’ve long supported requesting reviews from users, but now you can also configure Depfu to request from one or multiple of your teams.

In order to do this with the Github API we need the additional read-only permission, but since we’ve been asked about this many times we think the additional permission is worth it. If you don’t care about this feature you can also ignore the permission request and Depfu will continue to work just fine.

Assign multiple users to a PR

You can now assign multiple users to a PR, before this was limited to a single user from our side.

Gitlab

Review requests

Gitlab also recently added the concept of review requests, so you can now also configure Depfu to add reviewers when creating merge requests.

Assign multiple users to a MR

Multiple assignees are also possible on Gitlab, but only for Gitlab Enterprise Edition and Gitlab Premium accounts. So we’ll silently ignore additional users if we’re getting an error and only assign the first one you’ve configured.

Feedback

We’re always looking for small (and big) things that make your life with Depfu easier, smoother and calmer. So please don’t hold back on any feedback, we’re listening on Twitter and via email.

Depfu for PHP

Mon, 07 Jun 2021 00:00:00 +0000

For all the work that goes into supporting a new ecosystem, the blog posts are suprisingly boring, so let’s keep this one short:

Depfu now fully supports PHP with Composer.

That includes

Individual and Grouped Updates.
Our reasonably up-to-date strategy to get significantly fewer PRs.
Private package registries from your self-hosted Satis to Private Packagist.
Tracking of Security Vulnerabilities.
And everything else, of course.

We’ve been running this in production for quite some time now so we’ve ironed out most bugs and it’s stable and ready to be used.

Enjoy!

Auto-Merge, Nightshift and Auto-Activation

Wed, 24 Jun 2020 00:00:00 +0000

We wrapped up and polished a few smaller features recently that we had working in one form or another for individual customers. Let me tell you about them:

Auto-Merge

This does exactly what you think it does: Depfu will automatically merge a PR if and when all the status checks come back green.

You can configure to only auto-merge development or runtime dependencies and even specifically limit by SemVer type for very fine grained control.

⚠️ We advise to use this feature very cautiously: with compromised packages and continuous deployment you could quickly get into trouble. But for some projects it can make a lot of sense. You can also combine it with our reasonably up-to-date feature, which always waits at least 7 days before sending you the PR, to get a bit more safety.

Nightshift

Nightshift allows you to constrain the Depfu scheduler to a certain time of day and certain days of the week. This way you can tell Depfu to only send you PRs during your night time or during the weekend.

There are two main benefits:

Less PR noise during your working day and PRs are ready for you in the morning.
Depfu is not competing at all with your normal work, so we don’t use up CI capacity which could cause your developers to wait.

All security updates and manually triggered rebases will run outside of those limited hours, of course.

Auto-Activation

With Github apps you either select individual repos Depfu should run on or you select “all” repos. Originally, Depfu didn’t work with the “all” option, since we preferred to not have so much access.

But we had a few requests for enabling Depfu on every repo in an organization by default, especially from our Enterprise customers. So now you can! After selecting “all” in Github you can either choose individual repos yourself in Depfu or you enable Auto-Activation.

Auto-Activation enables all of your repos which are supported by Depfu. We also enable all future repos and repos that were initially empty, but later introduce package manager files we understand.

You can decide which update strategy newly activated repos should start with, for example by setting all of them to “Security Updates only” and then select other strategies individually per repo.

Feedback

We’re always looking for small (and big) things that make your life with Depfu easier, smoother and calmer. So please don’t hold back on any feedback, we’re listening on Twitter and via email.

Update your engines!

Wed, 17 Jun 2020 00:00:00 +0000

Ever since we started working on Depfu, we wondered if it would make sense to update the runtimes or, as we call it more generically: engines as well. Updating to a new Ruby or Node.js version is, very much like updating dependencies, an unloved chore with clear benefits when done regularly. Today we’ll start the beta test of this as a new Depfu feature.

On the surface, this feature doesn’t sound very complicated, but don’t be fooled. For dependencies, at least in the runtimes we support, there usually is a single (or double, if you count the lockfile separately) source of truth. For runtimes, things get complicated really, really fast. Even if you are using one of the version managers (Or, our new favourite, asdf-vm, the one version manager to rule them all), it’s not done by replacing the version number in .ruby-version, .node-version or .tool-versions. For ruby, a Gemfile could also specify a version (used by, for example, Heroku). For Node.js, the package.json can specify an arbitrarily complex version specificator in the engines compartment (of course it can, right?). What about your CI configuration? Do you use a Dockerfile to specify your base images?

Now in Beta!

The beta we’re launching today starts with support for the bare minimum of files to patch that sounded useful to us. Now we need to learn what other configuration files are important for you and where the patch strategies we’re initially starting with are falling over.

We’re starting with support for all three engines we’re supporting right now, so that’s Ruby, Node.js and Elixir. We support simple a Dockerfile, configs for CircleCI and Travis, and also, hopefully, a somewhat complete set of version manager configs for these three runtimes.

We’re also still pondering on how we can make it easier for 3rd parties (aka you!) to contribute to this. Do we need a generic, configurable way for you to support your overly specific hand crafted container config or would you rather directly contribute additional updaters if possible? This is an ongoing conversation but please tell us your ideas of course.

How you can test it

If you are already using Depfu, you can simply enable engine updates in the Depfu settings page. There are two settings, “Only Minor Engine Updates” and “Minor and Major Engine Updates” and these probably do what you expect: If you choose “Only Minor”, you will only get updates within your current major version line. If you choose “Minor and Major”, you will get updates for new major versions as well - As with normal dependency updates, the chances that something breaks spectacularly with those updates are higher, but if you treat the resulting pull/merge requests as the start of the update process, it may work for you.

We try to be somewhat smart with this, so for example, for Ruby, a project that doesn’t follow SemVer and instead treats major plus minor version as some sort of major version line, you will only get patch releases if you chose “minor”. It’s not your task to get caught up in nitpicky discussions about version semantics, right?

Halp!

Like I said, we need your help with this - if a config that stores an engine version in your repo is not properly updated it could be because of several reasons: Either we don’t support that file type yet or our updater’s way of patching the file content is way too naive. So please watch the diffs in these updates carefully and report any mistakes or missing files. And if you don’t feel like carrying that burden, that’s totally fine, too. Opting out can either be done via the project settings in the same way you turned the feature on or simply replying in the pull/merge request with @depfu pause - We’ll definitely let you all know as soon as we think that this feature is stable enough to not be called a beta anymore.