Override undici to 8.1.0

[DilumAluthge-LLM]

Related Issue

Related to #193 (but doesn't close it, because this PR just does an NPM override).

Summary

• add a root npm override so all transitive undici resolutions use 8.1.0
• regenerate package-lock.json so the resolved tarball and engine metadata point at undici@8.1.0
• rebuild dist/index.cjs so the checked-in action bundle matches the updated dependency graph

Why

undici is not a direct dependency in this repo. It is pulled in transitively by @actions/github and @actions/http-client, and the currently published @actions/* packages still depend on the 6.x line. This change moves the repo to the latest npm release of undici now instead of waiting for upstream package updates.

One Thing To Be Aware Of

This PR relies on an npm override because upstream @actions/* packages still declare undici ^6.23.0. The repo runs on node24, so undici@8.1.0 is engine-compatible here, but the key review point is that we are intentionally overriding transitive dependency ranges rather than getting this version through a normal upstream semver update.

Validation

• npm run lint
• make build
• make pack
• npm ls undici --all

🤖 Generated by OpenAI Codex.

[DilumAluthge]

@MichaelHatherly What do you think of this PR?

Pros and cons of overriding undici to v8:

• Pros: Earlier versions (undici v6 and v7) have a lot of CodeQL warnings. undici v8 seems to fix most of the CodeQL warnings. So by using undici v8, we may be using more secure code.
• Cons:
  • We have to do it via a npm override.
  • The @actions/* packages haven't upgraded to undici v8 yet. So in theory we could break something by overriding and forcing undici to be v8. However, our CI is green here, which is reassuring.

Pros and cons of staying on the current version (undici v6) and not overriding.

• Pros:
  • No need for an npm override.
  • No concerns about compatibility with our @actions/* dependencies.
• Cons: Might be using less secure code? Certainly CodeQL complains a lot about older undici versions (v6 and v7).

[MichaelHatherly]

I don't think that we should be doing this override. Are there specific known vulnerabilities that affect us here? My take is that we just let upstream upgrade their deps as an when they do.

[DilumAluthge]

Are there specific known vulnerabilities that affect us here?

You can see the CodeQL warnings here: https://github.com/julia-actions/install-juliaup/security/code-scanning

[MichaelHatherly]

The @actions/* packages haven't upgraded to undici v8 yet.

Maybe upstream would accept a patch? If it's not being worked on already?

[DilumAluthge]

The @actions/* packages haven't upgraded to undici v8 yet.

Maybe upstream would accept a patch? If it's not being worked on already?

The upstream repo (https://github.com/actions/toolkit) has several open issues and PRs, including:

• Issues:
  • Please update dependency undici actions/toolkit#2361
• PRs:
  • chore: bump undici to ^7.16.0 actions/toolkit#2205
  • Migrate from @azure/core-http to @azure/core-rest-pipeline and upgrade undici to v7 actions/toolkit#2206
  • feat: undici v7 actions/toolkit#2295
  • chore: consolidate dependabot and npm audit dependency updates actions/toolkit#2374

Regarding whether upstream would accept a PR from us, the repo's README says:

Thank you for your interest in this GitHub repo, however, right now we are not taking contributions.
...
While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time.