-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Description
Describe the bug
@actions/github v8 is exporting broken types.
To Reproduce
My CI (type check) breaking on upgrade should be self explanatory :
kevinmarrec/workflows#53
Still, you can check locally the types going crazy by reproducing the behavior:
- Clone https://github.com/kevinmarrec/workflows (main)
- Install dependencies
- Check types in filesize-diff/src/comment.ts ✅
- Checkout to renovate/actions-github-8.x branch
- Install dependencies
- Restart TypeScript Server AND/OR Reload IDE to refresh types cache
- Check types in filesize-diff/src/comment.ts ❌ (any)
Expected behavior
As the release did not specify related breaking change (except minimal Node.js version), the upgrade must be smooth and the types correct.
Additional context
Maybe unrelevant but here is a related Gemini conversation :
Conversation
It is clear from the files provided that the upgrade to @actions/github v8.0.0 introduces a significant regression in type inference.
The issue stems from the fact that v8 is a major architectural shift.
It upgrades internal @octokit dependencies from v5/v10 to v7/v17.
These newer Octokit versions have transitioned to pure ESM and have changed how types are exported and merged, which the @actions/github wrapper is currently failing to propagate.
⚠️ Issue Report: Broken Type Inference in v8.0.0
There is a confirmed issue with the @actions/github package after the v8 upgrade where the getOctokit client loses its type definitions and defaults to any.
1. Loss of Type Safety (The "Any" Leak)
As seen in your comparison screenshots, the TypeScript LSP (Language Server Protocol) is no longer able to resolve the return type of the Octokit client:
In v7: The octokit constant is correctly typed as an instance of GitHub & { rest: RestEndpoints; ... }.
In v8: The octokit constant is inferred as any.
2. CI Failures (noImplicitAny)
Because the client is now any, every subsequent property access (like .rest.issues.listComments) also returns any.
The Bug: When you pass a callback to a method like .find(), the parameters (e.g., comment) cannot be inferred.
The Error: Your CI is failing with error TS7006: Parameter 'comment' implicitly has an 'any' type. This occurs because your project likely has strict type checking enabled, which forbids implicit any types.
3. Underlying Dependency Conflict
The diff shows that @actions/github v8 upgraded @octokit/core to ^7.0.6 and @octokit/plugin-rest-endpoint-methods to ^17.0.0. These versions changed the way RestEndpointMethodTypes are structured.
The wrapper in @actions/github has not been updated to correctly map these new structures to the GitHub class it exports.
Recommendation
Until a patch is released for @actions/github to fix the getOctokit return type, you have two options:
- Temporary Workaround: Manually cast the response of your Octokit calls. You will need to install @octokit/plugin-rest-endpoint-methods as a dev dependency and use the RestEndpointMethodTypes to explicitly type your variables.
- Rollback: Pin your version to ^7.0.0 in package.json and configure Renovate to ignore the v8.0.0 update until a fix (likely a v8.0.1 or v8.1.0) is available.