Dependabot: Add npm entry so security update PRs can be rebased

[manzoorwanijk]

What?

Adds an npm entry to .github/dependabot.yml so that Dependabot security updates for npm packages have an owning config block. Version updates for npm remain disabled via open-pull-requests-limit: 0.

Why?

Dependabot security updates run from the repository's security settings, independently of dependabot.yml, and will open PRs for npm vulnerabilities even though we only configure the github-actions ecosystem today. Because there is no npm entry, those PRs have no owning config, so @dependabot rebase and @dependabot recreate both fail with a misleading message:

The dependabot.yml entry that created this PR has been deleted so this PR can't be rebased. Please close the PR so Dependabot can create a new one with the current dependabot.yml.

This leaves the only recourse as closing the PR and waiting for the next scan — see the loop on #75964. Adding an npm ecosystem entry gives these security PRs a config owner so rebase/recreate work, and lets us apply consistent labels and a cooldown.

We deliberately do not want to enable npm version updates across this monorepo, which would flood the repo with hundreds of PRs. Setting open-pull-requests-limit: 0 disables version updates while leaving security updates unaffected (the limit does not apply to them).

How?

• Add a package-ecosystem: 'npm' entry rooted at /.
• Set open-pull-requests-limit: 0 to keep version updates off while security updates continue.
• Apply a 7-day cooldown and the dependencies / [Type] Build Tooling labels, mirroring the existing github-actions configuration.

Testing Instructions

1. Confirm the YAML is valid and parses (e.g. npx js-yaml .github/dependabot.yml or any YAML linter).
2. After merge, the next Dependabot npm security PR should accept @dependabot rebase / @dependabot recreate instead of reporting a missing config entry, and should carry the configured labels.
3. Verify no new npm version-update PRs are opened (only security updates).

Use of AI Tools

This PR was drafted with the assistance of Claude Code. All changes were reviewed by the author.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: manzoorwanijk <manzoorwanijk@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: desrosj <desrosj@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Flaky tests detected in 295ac56.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/27321031938
📝 Reported issues:

• [Flaky Test] shouldn't conflict with server-side autosave #78706 in /test/e2e/specs/editor/various/autosave.spec.js

[aduth]

I'd be curious if folks like @desrosj would be interested to keep and continue maintaining the dependency updates for non-security updates? There's some engagement here on our part.

[aduth]

I'm trying to understand this configuration in relation to the behavior you describe in the original comment. If security updates don't consider dependabot.yml, then what's the point of adding cooldown and labels here? Will security updates consider those aspects of the configuration (which for labeling would be great to avoid a little bit of maintainer tedium)? And would we want a cooldown for security updates, or want those immediately?

[manzoorwanijk]

Good catch! When a matching ecosystem entry exists, security PRs honor labels (on the default branch) but not cooldown ("only available for version updates"). open-pull-requests-limit is also ignored by security updates.

So labels is the point - it removes the manual labeling tedium you linked. cooldown is inert here (and we wouldn't want to delay security fixes anyway). I'll update it.

[aduth]

Thanks for checking and sharing the resource 👍 Glad that the labels will be applying.

[aduth]

Could we add the configuration without disabling the version updates, and would that help with the root issue of Dependabot's inability to rebase, and the application of a "[Type]" label that our CI enforces?

I'm not as sure about disabling the version updates. Looking through historical pull requests with the "dependencies" label, @desrosj seems quite engaged with these.

[desrosj]

I'm not as sure about disabling the version updates. Looking through historical pull requests with the "dependencies" label, @desrosj seems quite engaged with these.

All of the npm-related Dependabot PRs that I have interacted with so far have been related to vulnerability reports. To my knowledge, no non-security PRs are being created by the bot.

Because there is no npm entry, those PRs have no owning config, so @dependabot rebase and @dependabot recreate both fail with a misleading message

I'm not certain that the lack of a configuration is the reason that Dependabot is unable to perform any desired actions on a given PR. My interpretation was that the dependabot.yml file had been modified after the pull request had been opened. The file is not updated often, but there have been 2 changes so far this year. If my understanding is correct, any PR created prior to May 22, 2026 will not be able to rebase/recreate.

It looks like all of the open Dependabot PRs were created prior to this date. To see if this could be confirmed, I looked at #77655. It was created in April 2026, and was last rebased successfully on May 12, 2026. I just tried to rebase again with @dependabot rebase and received the message about the Dependabot entry being deleted.

All this said, it appears accurate that there is no way to override the default labels without defining an entry in the configuration file. I think this is probably fine to merge to ensure those are properly assigned when the PR is created. However, I do lean towards not explicitly calling out that the entry configures security updates and instead note that npm updates in general are being disabled. I don't feel strongly about that, though.

[manzoorwanijk]

We can evaluate it after merge.

[manzoorwanijk]

Dependenabot is a useless createion - it still doesn't seem to work - #75964 (comment)

[desrosj]

@manzoorwanijk were you expecting it to retroactively work for old PRs? That was not my expectation, so curious what you had in mind.

I agree that it's annoying when any change to the configuration file results in the PR being unable to be updated with the bot, but let's see how this goes as new PRs are created.

Also, if the expectations are more clear and the full team does a better job keeping up with these, we won't end up with this many old PRs, which will minimize this scenario.

[manzoorwanijk]

@manzoorwanijk were you expecting it to retroactively work for old PRs? That was not my expectation, so curious what you had in mind.

my expectation was that @dependabot recreate comment would work for PRs created before this change.

I agree that it's annoying when any change to the configuration file results in the PR being unable to be updated with the bot, but let's see how this goes as new PRs are created.

Also, if the expectations are more clear and the full team does a better job keeping up with these, we won't end up with this many old PRs, which will minimize this scenario.

I think it may work if we enable the version updates by setting the pull request number to greater than 0.