Dependabot Groups include Unexpected Dependencies when Updating Existing PR

[kahagerman]

Is there an existing issue for this?

• [X] I have searched the existing issues

Package ecosystem

pnpm (applies to all)

Package manager version

pnpm=8.9.2 (likely applies to all)

Language version

node=20

Manifest location and content before the Dependabot update

N/A

dependabot.yml content

(Edited down from full monorepo config:)

---
version: 2
updates:
  - directory: /web
    commit-message:
      prefix: Web
    package-ecosystem: npm
    open-pull-requests-limit: 3
    schedule:
      interval: weekly
      day: monday
      time: '05:00'
      timezone: America/Toronto
    versioning-strategy: increase-if-necessary
    allow:
      - dependency-type: all
    groups:
      major:
        update-types: [major]
      minor:
        patterns:
          - '*' # everything else - minor, patch, etc.

Updated dependency

N/A

What you expected to see, versus what you actually saw

When manually updating a PR via dependabot (i.e. by running @dependabot recreate, or similar commands), dependencies which should not be included in the PR are added to it.

From the documentation for groups:

Dependabot creates groups in the order they appear in your dependabot.yml file. If a dependency update could belong to more than one group, it is only assigned to the first group it matches with.

This implies that the following config snippet:

    groups:
      major:
        update-types: [major]
      minor:
        patterns:
          - '*' # everything else - minor, patch, & indirect dependencies

Should not include "major" semver updates in the minor group.

However, this filtering is not applied when a dependabot run is based on an existing pull request:

Before:

After running @dependabot recreate:

(Note: I have no idea why this shows "with 19 updates", but this is unrelated.)

Native package manager behavior

N/A

Images of the diff or a link to the PR, issue, or logs

Full dependabot run logs

Here are some relevant specifics:

• Two groups exist:

  "dependency-groups":[{"name":"major","rules":{"update-types":["major"]}},{"name":"minor","rules":{"patterns":["*"]}}],
  

• Minor group is being updated:

  "dependency-group-to-refresh":"minor"
  

• Existing PR is detected, and has one dependency:

  "existing-group-pull-requests":[{"dependency-group-name":"minor","dependencies":[{"dependency-name":"antd","dependency-version":"5.20.2","directory":"/web"}]}]
  

• PR is recreated with major (as defined by semver) version bumps:

  +---------------------------------------------------------------------------------------------------------------------------------------------------------+
  |                                                           Changes to Dependabot Pull Requests                                                           |
  +------------------------------+--------------------------------------------------------------------------------------------------------------------------+
  | closed: dependencies_changed | antd                                                                                                                     |
  | created                      | @vitest/coverage-v8 ( from 1.6.0 to 2.0.5 ), vitest ( from 1.6.0 to 2.0.5 ), antd ( from 5.20.0 to 5.20.2 ), @vitest/... |
  +------------------------------+--------------------------------------------------------------------------------------------------------------------------+
  

Smallest manifest that reproduces the issue

---
version: 2
updates:
  - directory: /
    package-ecosystem: npm
    groups:
      major:
        update-types: [major]
      minor:
        patterns:
          - '*' # everything else - minor, patch, etc.

Debugging Help / Recommendation:

When deciding which updates may be included, this job should not only check that the dependency is applicable to the current PR's group, but also verify that it is not applicable to any previous group.

If a given dependency is applicable to a previous group, that group will pick up the dependency when it is re-evaluated.

This would make the behaviour consistent between an "inital" run (when no PRs exist), and an "update" run (when one or more PRs already exist).