Add missing deps #717
Add missing deps #717
Conversation
WalkthroughDependencies updated to replace TypeScript-specific tooling with Octokit and modern ESLint configuration libraries. Type assertion in release.ts modified to use explicit cast through unknown intermediate type. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes
Possibly related PRs
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
bot
added
dependencies
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
package.json (1)
13-39: Critical:eslint-import-resolver-typescriptremoval is incomplete — ESLint config still references it.The eslint.config.mjs contains
'import/resolver': { typescript: { ... } }configuration, but the package was removed. This will cause ESLint to fail at runtime with a missing resolver error. Either:
- Reinstate
eslint-import-resolver-typescriptin devDependencies, or- Update eslint.config.mjs to remove the typescript resolver setting and use the built-in node resolver instead
ts-noderemoval is safe — no references found in the codebase.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
dist/index.jsis excluded by!**/dist/**dist/index.js.mapis excluded by!**/dist/**,!**/*.mapyarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (2)
package.json(2 hunks)src/release.ts(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
src/release.ts (1)
dist/index.js (7)
releases(45854-45857)releases(45889-45889)client(48039-48039)context(45254-45254)context(45851-45851)context(45888-45888)context(48027-48027)
🔇 Additional comments (1)
package.json (1)
15-15: LGTM! Modern ESLint configuration dependencies added.The additions of
@eslint/eslintrcandglobalsalign with modern ESLint configuration practices, replacing the older TypeScript-specific resolver.Also applies to: 31-31
| const releases = (await client.paginate(client.rest.repos.listReleases, { | ||
| ...context.repo, | ||
| per_page: 100, | ||
| }) | ||
| })) as unknown as Release[] |
There was a problem hiding this comment.
🧩 Analysis chain
Verify the necessity of the double type assertion.
The double cast through unknown (line 31) suppresses TypeScript's type checking and may hide legitimate type incompatibilities between client.paginate's return type and Release[]. This pattern is typically a workaround rather than a proper solution.
Run the following script to check if there's a type mismatch or if a better approach exists:
Additionally, consider searching the web for the latest Octokit documentation to verify the correct typing approach:
🏁 Script executed:
#!/bin/bash
# Description: Check the type definitions and usage of client.paginate to understand the type mismatch
# Check the return type of client.paginate in the codebase
rg -n -A 5 -B 5 "client\.paginate.*listReleases" --type=ts
# Look for the type definition of Release in the codebase
ast-grep --pattern 'type Release = $$$'
# Check for other usages of Octokit types to see if similar patterns exist
rg -n "as unknown as.*\[\]" --type=tsLength of output: 712
🌐 Web query:
@octokit/plugin-paginate-rest typescript listReleases return type
💡 Result:
When you call octokit.paginate for the releases endpoint, the TypeScript return type is:
Promise<PaginatingEndpoints["GET /repos/{owner}/{repo}/releases"]["response"]["data"]>
which (per the plugin's type helpers) resolves to the releases array type (i.e. the endpoint response's data — an array of release objects). [1][2]
Sources:
- README / usage & types for @octokit/plugin-paginate-rest. [1]
- dist-types/types.d.ts (GetResultsType / PaginatingEndpoints typings). [2]
And let me search for more information about the correct typing approach:
🏁 Script executed:
#!/bin/bash
# Check how client is defined and typed
rg -n -B 10 "const releases = \(await client.paginate" src/release.ts --type=ts
# Look for client initialization
rg -n "const client\s*=" src/release.ts --type=ts
# Check imports in release.ts
head -20 src/release.ts
# Look for @octokit imports and types
rg -n "@octokit" src/release.ts --type=ts
# Search for getOctokit or similar client creation patterns
rg -n "getOctokit|github\.rest" src/release.ts --type=tsLength of output: 293
🌐 Web query:
Octokit paginate listReleases correct TypeScript type Release array
💡 Result:
Use the paginate plugin's PaginatingEndpoints types to get the exact response data type. Example:
-
Install/import:
import { Octokit } from "@octokit/core";
import { PaginatingEndpoints } from "@octokit/plugin-paginate-rest"; -
Extract the releases array type and use it:
type Releases = PaginatingEndpoints["GET /repos/{owner}/{repo}/releases"]["response"]["data"];
const octokit = new Octokit({ auth: TOKEN });
const releases: Releases = await octokit.paginate("GET /repos/{owner}/{repo}/releases", { owner, repo });
This yields the correct Release[] type (as defined by the Octokit paginate typings). [1][2]
Sources:
[1] @octokit/plugin-paginate-rest README / types.
[2] plugin-paginate-rest types (dist-types).
---
🏁 Script executed:
```shell
#!/bin/bash
# Check how client is defined and typed in release.ts
rg -n -B 15 "const releases = " src/release.ts --type=ts | head -30
# Look for client initialization/parameter
rg -n "function\|export\|const.*client" src/release.ts --type=ts | head -20
# Check imports in release.ts
head -30 src/release.ts
# Look for @octokit imports and version in package.json/package-lock.json
rg -n "@octokit" . --type=json
Length of output: 1689
---
🌐 Web query:
```web
@actions/github getOctokit paginate plugin type Return type
💡 Result:
Short answer: getOctokit(...) returns an Octokit instance type (InstanceType) that includes whatever plugin types you pass in — so when you pass @octokit/plugin-paginate-rest the .paginate method is typed by the plugin (PaginateInterface / PaginatingEndpoints). In other words:
- getOctokit(...) return type: InstanceType. [1]
- @octokit/plugin-paginate-rest exports PaginateInterface and PaginatingEndpoints; .paginate overloads are typed via those so returned Promise item types come from PaginatingEndpoints[Key]["response"]["data"]. Example pattern: Promise<DataType<PaginatingEndpoints[E]["response"]>>. [2][3]
Example (TypeScript):
- const octokit = getOctokit(token, {}, paginateRest);
- // octokit has octokit.paginate(...) with the plugin's typed overloads (PaginateInterface / PaginatingEndpoints). [1][2]
Sources:
[1] @actions/github getOctokit signature.
[2] @octokit/plugin-paginate-rest README (PaginateInterface / PaginatingEndpoints).
[3] composePaginateRest type example showing DataType extraction.
---
🌐 Web query:
```web
OctoOpenApiTypes schemas release Octokit paginate compatibility type mismatch
💡 Result:
I don’t have enough detail to diagnose the exact mismatch. Please paste the TypeScript error message and your package versions (especially @octokit/openapi-types, @octokit/types, @octokit/plugin-paginate-rest / @octokit/rest / @octokit/core). Meanwhile try these quick checks:
- Pin or roll back @octokit/openapi-types to the last working version (or pin @octokit/* packages to compatible versions) — type regressions often come from a newer openapi-types release. [1]
- Update all Octokit packages together so their @octokit/types & openapi-types expectations align (plugin-paginate-rest exposes PaginatingEndpoints types used by paginate). [1][2]
- If using composePaginateRest / paginate with endpoint keys, ensure you use the PaginatingEndpoints type utilities from @octokit/plugin-paginate-rest to get correct parameter/response types. [1]
- If the error persists, paste the exact TS error and your package.json / lockfile and I’ll give a targeted fix (or a minimal tsconfig/type override).
References:
[1] @octokit/plugin-paginate-rest README (types & PaginatingEndpoints).
[2] example lockfile snippet showing @octokit/openapi-types alongside plugin-paginate-rest.
Remove the double type assertion and use explicit type annotation instead.
The double cast through unknown is a workaround for type incompatibility. The @actions/github getOctokit() method returns an Octokit instance with the paginate plugin's types properly included, and .paginate should return correctly typed arrays through PaginatingEndpoints. Rather than suppressing type checking, explicitly annotate the variable:
const releases: Release[] = await client.paginate(client.rest.repos.listReleases, {
...context.repo,
per_page: 100,
})If TypeScript errors remain, verify that @octokit package versions (@octokit/openapi-types, @octokit/plugin-paginate-rest, @octokit/types) are aligned and compatible with each other, as type regressions can occur from version mismatches between @octokit packages.
🤖 Prompt for AI Agents
In src/release.ts around lines 28 to 31, remove the double type assertion
through unknown and give the variable an explicit type annotation (e.g., const
releases: Release[] = await client.paginate(...)) so TypeScript can properly
type the result; if that still errors, ensure your @octokit packages
(openapi-types, plugin-paginate-rest, types) are version-aligned and update or
pin them so paginate returns the correct typed array.
Summary by CodeRabbit