Jan Krutisch, Co-Founder at Depfu

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.