 [ ← blog / drupal ](/) Jan 04, 2024  ·  \#drupal  ·  6 min read 

# My Dependabot configuration for Drupal (and other PHP projects)



I use GitHub to host my repositories, such as this website. To keep my dependencies up-to-date, I leverage [Dependabot](https://github.com/dependabot). The product has matured *a lot* over the past few years. Before, it was a standalone service and then [acquired by GitHub](https://github.blog/2019-05-23-introducing-new-ways-to-keep-your-code-secure/#automated-security-fixes-with-dependabot). It did not support dependencies managed by Composer. It was pretty spammy and very noisy. However, it has drastically improved over the past few years. Thanks to all of those at GitHub who have worked to improve it (that includes you, [Mike Crittenden](https://critter.blog/).)

My Dependabot configuration consists of a few items, nothing overly specific.

- Defining each ecosystem in my repository (GitHub Actions, Composer, NPM)
- Specifying a schedule for that ecosystem
- Setting up ignore rules, such as avoiding major version bumps
- Defining groups to combine packages that have batched releases.

I'll walk through the different configuration options. At the end of the blog post, I have two examples: one for my blog and another for a Laravel application with a Vue.js frontend. I recommend reading the [full documentation for the `dependabot.yml` configuration options](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file), as I barely scratch the surface of my usage.

To configure Dependabot, you must have the `dependabot.yml` file in your `.github` directory.

First, all `dependabot.yml` files must start with the `version` key and contain an `updates` key. All of the package ecosystem configurations will go as an array under `updates`.

```yaml
version: 2
updates:
  -
```

Now we can start flushing out the file.

## Defining ecosystems for dependency updates

Since we're working with a Drupal site, we have Composer as a package ecosystem.

```yaml
version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/"
```

The `directory` key is required; Dependabot doesn't provide a default. This tells Dependabot that there is a `composer.json` and `composer.lock` file in the root of the repository (`/`).

More than likely, the Drupal theme uses tooling for CSS and JavaScript, so we need to add NPM as an ecosystem. In my experience, projects end up having the `package.json` in the theme directory rather than in the project's root.

```yaml
version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/"

  - package-ecosystem: "npm"
    directory: "/web/themes/custom/mytheme"
```

This assumes the `package.json` and relevant lock file (`yarn.lock` or `package-lock.json`) is located at `web/themes/custom/mytheme`. If you're using Yarn or pnpm over NPM, the ecosystem key is still `npm`.

Let's say your Drupal project uses GitHub Actions for its continuous integration workflows. If you're using any GitHub Actions, those are also versioned and must stay updated. We can add the GitHub Actions ecosystem for that.

```yaml
version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/"

  - package-ecosystem: "npm"
    directory: "/web/themes/custom/mytheme"
    
  - package-ecosystem: "github-actions"
    directory: "/"
```

Note, for GitHub Actions, you do not need to specify the directory as `.github/workflows`, only `/`.

Now, we'll begin to receive automatic updates for dependency! But, Dependabot will assign a random schedule for delivering them. Leading to chaos and a lot of frustration with earlier versions of Dependabot.

## Specifying a schedule to more easily manage dependency updates

I like to receive my updates weekly. You can have it run [daily, weekly, or monthly](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#scheduleinterval). Dependabot seems to have a limit on the number of updates it'll provide, so I wish you could configure specific days, like Monday and Thursday in case you have a lot of dependencies that may have been updated.

```yaml
version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "npm"
    directory: "/web/themes/custom/mytheme"
    schedule:
      interval: "weekly"    

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
```

By default, weekly updates are delivered on Monday but can be configured to a specific day of the week.

```yaml
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "tuesday"
```

Now, we've got scheduled updates to wrangle in dependency management chaos.

## Setting up ignore rules to wrangle unwanted version bumps

What irritates me about Dependabot is how it will make a pull request to bump a dependency to a whole new major version when it does not match your semantic version constraints. For example, I had `drupal/core-recommended` set to `~9.5.0` in my `composer.json`. When Drupal 10.0.0 was released, I received a pull request bumping `drupal/core-recommended` to 10.0.0. That's not a valid update.

Luckily, we can use [`ignore` to specify rules](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#ignore) for ignoring specific dependencies or types of updates.

```yaml
version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"
    ignore:
      - dependency-name: "drupal/core*"
        update-types: ["version-update:semver-major"]
```

This uses a wildcard to tell Dependabot to ignore major version updates for `drupal/core`, `drupal/core-recommended`, `drupal/core-composer-scaffold`, and `drupal/core-dev`. In the examples at the end, I also use the same for Symfony and Laravel.

Instead of using `update-types` you can also use `versions` to ignore specific versions. I don't recommend this for Composer dependencies, as you should use the [`conflict` package links](https://getcomposer.org/doc/04-schema.md#conflict).

Now, let's group related updates to reduce pull requests for framework packages.

## Grouping dependency updates

I was excited once Dependabot rolled out the [grouped version updates](https://github.blog/changelog/2023-08-24-grouped-version-updates-for-dependabot-are-generally-available/). When working with frameworks that have multiple packages released simultaneously, it combines the updates into one pull request. This helps avoid spam when Drupal core has a release, and you have to upgrade `drupal/core` and `drupal/core-composer-scaffold` along with the metapackages `drupal/core-recommended` and `drupal/core-dev`. The same goes for other frameworks with various components that may be released simultaneously, such as Symfony or Laravel.

```yaml
version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"
    ignore:
      - dependency-name: "drupal/core*"
        update-types: ["version-update:semver-major"]
    groups:
      drupal-core:
        patterns:
          - "drupal/core*"
```

We can use `*` for wildcards here, as well.

## Examples

Here is the `dependabot.yml` for my Drupal site. I use the Gin theme, which has companion modules, Gin Toolbar and Gin Login, also released at similar intervals. So I grouped them as well.

```yaml
version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"
    ignore:
      - dependency-name: "drupal/core*"
        update-types: ["version-update:semver-major"]
    groups:
      drupal-core:
        patterns:
          - "drupal/core"
          - "drupal/core-composer-scaffold"
          - "drupal/core-recommended"
          - "drupal/core-dev"
      gin:
        patterns:
          - "drupal/gin"
          - "drupal/gin_login"
          - "drupal/gin_toolbar"
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
```

Here is one from a Laravel application that uses a Vue.js frontend. I grouped the Symfony and Laravel updates and ignored major version updates.

```yaml
version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"
    ignore:
      - dependency-name: "symfony/*"
        update-types: ["version-update:semver-major"]
      - dependency-name: "laravel/*"
        update-types: ["version-update:semver-major"]
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
```

Here is my [configuration file](https://github.com/mglaman/drupal-mrn/blob/main/.github/dependabot.yml) for [drupal-mrn.dev](https://drupal-mrn.dev/), a monorepo containing a backend API and single page application frontend.

```yaml
version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/api"
    schedule:
      interval: "weekly"
  - package-ecosystem: "npm"
    directory: "/api"
    schedule:
      interval: "weekly"
  - package-ecosystem: "npm"
    directory: "/app"
    schedule:
      interval: "weekly"
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
```

 

  ![](/themes/custom/mglaman/images/headshot.webp)Thanks for reading

I write about Drupal, PHP, and the quiet infrastructure behind large sites — caching, config, and testing. New posts land every week or two.

 [Subscribe via RSS →](/rss.xml) [About me →](/about-me) 

 



 

  [← Older

Looking back on 2023

 ](/blog/looking-back-2023) [Newer →

Building my career, thanks to the opportunity of open source

 ](/blog/building-my-career-thanks-opportunity-open-source)