[WIP] Analysis only for Dependabot alerts in yarn/npm ecosystem

[Copilot]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

Original prompt

User requested analysis-only guidance (no PRs/issues) for Dependabot alerts in VATSIM-UK/uk-controller-api focusing on yarn/npm ecosystem. Do not create PR. No code changes requested.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: I need to get rid of the security issues such as

@semantic-release/github@12.0.6 requires undici@^7.0.0
semantic-release@25.0.2 requires undici@^7.0.0 via a transitive dependency on @semantic-release/github@12.0.6
semantic-release@25.0.2 requires undici@^5.28.5 via a transitive dependency on @actions/http-client@3.0.1

Assistant: You can’t “migrate away” from those particular issues by swapping Commitizen—those warnings are coming from your release tooling dependency graph (semantic-release + @semantic-release/github + GitHub Actions libraries), and the fix is to update the semantic-release toolchain (and/or pin/override undici) so you’re no longer pulling vulnerable/flagged undici majors.

Based on what you pasted, you currently have:

• @semantic-release/github@12.0.6 → requires undici@^7
• semantic-release@25.0.2 → pulls @semantic-release/github@12.0.6 → undici@^7
• semantic-release@25.0.2 → also pulls @actions/http-client@3.0.1 → undici@^5.28.5

What to do (in order of “cleanest”)

1) Upgrade semantic-release + @semantic-release/github (best fix)

This is the most correct remediation because it updates the packages that declare those dependencies.

In package.json devDependencies, bump at least:

• semantic-release
• @semantic-release/github

And ideally bump the whole semantic-release plugin set together:

• @semantic-release/commit-analyzer
• @semantic-release/release-notes-generator
• @semantic-release/changelog
• @semantic-release/git
• @semantic-release/github
• semantic-release

Then run yarn install and re-check the tree (yarn why undici) to confirm you’re no longer stuck on old/vulnerable ranges.

Why this works: newer versions often update their dependency constraints and/or update transitive GitHub Action libs.

If you tell me what package manager version you’re using (Yarn classic vs Berry) I can give exact commands; generally:

yarn add -D semantic-release@latest \
  @semantic-release/github@latest \
  @semantic-release/commit-analyzer@latest \
  @semantic-release/release-notes-generator@latest \
  @semantic-release/changelog@latest \
  @semantic-release/git@latest

2) If you can’t upgrade, force a safe undici via overrides/resolutions

If you’re blocked from upgrading semantic-release right now, you can often mitigate by forcing a newer patched undici version across the tree.

Yarn classic (v1): use resolutions

Add to package.json:

"resolutions": {
  "undici": "^7.0.0"
}

…but note: this won’t fix the undici@^5.28.5 path unless Yarn can legally unify it. If a dependency is truly constrained to ^5, Yarn may keep 5.x alongside 7.x.

Yarn Berry (v2+): use resolutions / packageExtensions

Berry gives you more control, but same fundamental constraint issue: you can’t force a dependency outside its allowed semver range without risking breakage.

So: overrides are a stopgap, not the preferred fix.

3) Reduce dependency surface: remove @semantic-release/github (only if acceptable)

If your release process doesn’t actually need GitHub Releases / PR comments / assets, you can drop @semantic-release/github from your semantic-release plugins list. That would remove one major consumer of undici.

But your config currently uses @semantic-release/github, and your workflow uses tokens; you probably do want GitHub Releases. So consider this only if you’re okay with “tags + changelog commit” but not GitHub Releases.

---

What I need from you to make this precise

To recommend the exact upgrade targets (and avoid breaking changes), I need one of:

1. Paste your yarn.lock (or at least the undici, @semantic-release/github, @actions/http-client sections), or
2. Tell me:
   • Are you using Yarn v1 or Yarn v3/v4?
   • Do you require semantic-release to publish GitHub Releases, or are tags/changelog commits enough?

With that, I can give you an exact minimal-change plan like:

• “Upgrade X to version Y, leave others pinned”
• and if needed, a resolutions stanza that actually unifies the tree.

Also: the snippet you posted includes actions/checkout@v6 and actions/setup-node@v6 in workflows—those @v6 tags don’t look right (current major versions have historically been lower). If those are real in your repo, that’s another potential supply-chain/security issue worth correcting—but we should verify against the repo state you’re actually running.

User: how to bump all dependencies

Assistant: To bump all dependencies in VATSIM-UK/uk-controller-api, do it at two levels:

1. Composer (PHP) deps
2. Yarn (Node) deps (where your semantic-release/undici issues ...

This pull request was created from Copilot chat.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud