💡 Create MRs or GitLab Issues for Abandoned / Deprecated Dependencies

[chauncey-garrett]

Tell us more.

Summary

Renovate already detects and lists abandoned or deprecated dependencies in the dependency dashboard. However, these often remain invisible to most developers since they don’t trigger any notifications, merge requests, or issues.

This proposal suggests adding an option for Renovate to create GitLab Merge Requests and/or GitLab Issues when such dependencies are detected — to give these findings greater visibility and make them actionable.

Problem Statement

Currently:
• Abandoned or deprecated dependencies are only visible in the Renovate Dependency Dashboard.
• Teams often miss these warnings, leading to outdated or unmaintained packages lingering in production.
• There’s no automated or trackable workflow to address these risks.

As a result, potential security, compatibility, or maintenance risks remain hidden until a manual audit is performed.

Proposed Solution

✅ Option 1: Create Merge Requests

When Renovate detects an abandoned or deprecated dependency:
• Open a dedicated MR per package to remove it.
• Include a clear commit message and body:

chore(deps): remove abandoned dependency

MR body:

Renovate has identified as abandoned or deprecated.

🧩 Dependency:
📦 Current Version: x.y.z
📉 Reason: Marked as abandoned/deprecated by package registry
🧰 Action: Dependency removed from manifest

⚠️ This MR will NOT auto-merge even if automerge is enabled globally.

• Apply automerge: false explicitly for safety.
• Add labels like dependency:abandoned or renovate:abandoned.
• Use a separate branch for each, e.g., renovate/abandoned-.

📝 Option 2: Create GitLab Issues

If safe removal isn’t feasible:
• Create a GitLab Issue per package instead.
• Title:

Investigate abandoned dependency
• Include in the description:
• Package name, version, and reason for abandonment.
• Suggested replacements or alternatives (if available).
• Links to relevant registry pages or advisories.
• Assign labels and (optionally) team assignees, e.g. @team/sre.

⚙️ Option 3: Configurable Behavior

Proposed configuration in .renovaterc:

{
  "abandonedDependencyAction": "mr", // or "issue", "disabled"
  "abandonedDependencyAutomerge": false,
  "labels": ["dependency:abandoned"],
  "issueAssignees": ["@team/sre"],
  "branchPrefix": "renovate/abandoned-"
}

Benefits

• 🔎 Visibility: Makes abandoned/deprecated dependencies visible in GitLab instead of being buried in dashboards.
• 🧠 Actionability: Creates real, trackable work items (MRs or Issues).
• 🧾 Traceability: Maintains a record of dependency removal or replacement decisions.
• 🧯 Safety: Keeps automerge disabled by default for these changes.

Additional Considerations

• One dependency per MR (to ensure safe and reviewable diffs).
• Should only run when explicitly enabled.
• If deprecation notice includes replacement suggestions, include them in the MR or issue body.
• Future extension: similar flow could apply for deprecated → replacement migrations (e.g., express-session → @express/session).

Example Scenario

Renovate detects that left-pad has been marked abandoned.

It opens a Merge Request titled:
chore(deps): remove abandoned dependency left-pad

The MR removes left-pad from package.json, disables automerge, and applies a dependency:abandoned label.

If removal is unsafe, instead an issue is created:
Investigate abandoned dependency left-pad.

[RahulGautamSingh]

Creating PRs

I think will be bit hard cause we will have to think about

1. removing the dep strings from package files, which will very manager-to-manager OR
2. we will need to use manager specific commands like npm uninstall or yarn remove

This means all managers have to be updated which can take too long

Issues

We could add a new option like abandonedDepsIssue=true|false. If set to true & if there are abandoned deps present this will create a new issue for them. This can be done during the ensureDependencyDashabord phase.

[chauncey-garrett]

I think an added benefit of creating an issue for dep removal (vs simply surfacing in the Dependency Dashboard) is that an AI agent can then be assigned the Issue and begin work refactoring the codebase for its removal.

[MShekow]

We suffer from the same problem. Developers never look at the dependency dashboard, since we set prConcurrentLimit to 0 anyway. Our devs only look at PRs.

Why not simply have the PR make a dummy change (e.g. create a random file)? I don't think you need to postpone this just because it would be so hard to correctly implement the removal of the abandoned dependency.

[GideonBear]

Why not simply have the PR make a dummy change (e.g. create a random file)?

It should probably just open an issue instead.

[MShekow]

In the enterprise settings where I work, developers don't look at the GitHub issues, because issues are handled in (drumroll) Jira. That's the underlying reason why, in my setting (as a softtware developer contractor company), our dev teams never look at the dependency dashboard. Because they don't look at issues at all.

[GideonBear]

That's fair, although I still think opening dummy PRs is (even though it might be a good fit for your usecase) a bit weird.
I wouldn't be opposed to it being an option though

[MShekow]

I agree with your perspective. Dummy PRs are weird. Having a configuration option where one can choose between "do nothing" (the default, and current state), "create an issue", or "create a dummy PR" would be great.