chore: upgrade octokit to v5 and probot to v14 by Miablo · Pull Request #484 · github-community-projects/private-mirrors

Miablo · 2026-06-15T16:07:33Z

Pull Request

This PR will update Octokit and Probot along with updating any files based on the various majors we are updating to.

Closes #329

fixed merge conflicts from #477

Proposed Changes

Upgrades Probot 13 → 14.3.2 and Octokit 3 → 5, aligning the entire @octokit/core dependency tree to a single deduped v7.0.6.

Key changes:

probot 13.4.7 → 14.3.2
octokit 3.2.2 → ^5.0.5
@octokit/auth-app 6.1.1 → ^7.1.5
next-auth 4.24.12 → 4.24.14 (fixes nodemailer peer dependency conflict)
@probot/octokit-plugin-config added at ^4.0.0
@octokit/openapi-webhooks-types-transition replaces @octokit/webhooks-types for test types
createNodeMiddleware() now awaited (async in Probot 14)
Legacy REST shortcuts replaced with context.octokit.rest.*
z.instanceof(Octokit) → z.custom() (Octokit v5 class structure no longer supports instanceof)
Non-null assertions added for repository.owner (nullable in Octokit v5 webhook types)

Type workarounds

as any on DataTable columns (3 page files)

Why: @primer/react's DataTable component uses ObjectPaths<Data> for the field prop type. Under moduleResolution: "bundler" (from @tsconfig/next), the generic Data parameter isn't inferred from the data prop and falls back to UniqueRow, which only exposes "id" as a valid field. This is a known issue with @primer/react's draft DataTable generics.

When to remove: When @primer/react updates DataTable to support moduleResolution: "bundler", or when DataTable moves out of drafts with fixed generic inference.

@ts-expect-error on custom properties API (repos/controller.ts)

Why: rest.orgs.getAllCustomProperties() and rest.orgs.createOrUpdateCustomProperty() exist in the GitHub API and work at runtime, but octokit 5's bundled REST types (@octokit/plugin-rest-endpoint-methods) have not yet added these endpoints to their type definitions.

When to remove: When @octokit/plugin-rest-endpoint-methods adds the custom properties endpoints tracked upstream | tracked locally in #485

@ts-expect-error on 'internal' visibility (repos/controller.ts)

Why: The visibility parameter for repos.createInOrg only types "private" | "public" in octokit 5, but "internal" is a valid value for GitHub Enterprise/GHEC orgs.

When to remove: When octokit's REST types add "internal" to the visibility union.

PR #477 Follow-ups

`useForks.tsx:19` — `satisfies` over `as`

`satisfies` doesn't apply here — the cast is needed because `.catch(() => error.data)` widens
the return type to `ForksObject | undefined`, breaking inference on `res`. `satisfies` checks
that a value conforms to a type but doesn't narrow it, so `res.organization` would still error.
The `as ForksObject` is safe because the paginate generic is already `<ForksObject>` and `.catch`
returns the same shape via `error.data`.

`forks/[forkId]/page.tsx:570` — `satisfies` over `as`

`satisfies` won't resolve this one. The root issue is that under `moduleResolution: "bundler"`
(from `@tsconfig/next`), DataTable's `Data` generic isn't inferred from the `data` prop and falls
back to `UniqueRow`, which only exposes `"id"` as a valid `field` value. `satisfies` checks shape
conformance but doesn't change how the generic is inferred — entries like `field: 'name'` would
still error. Updated the comment in the code to explain this. The workaround stays until
`@primer/react` fixes generic inference for DataTable (currently a draft component).

`controller.ts:37` — tracking issue

Added the upstream octokit discussion link (https://github.com/octokit/octokit.js/discussions/2050)
directly to the `@ts-expect-error` comment in the code. Will file a tracking issue on this repo as a
follow-up so we have a local TODO to remove the suppression once the upstream types are updated.

`tsconfig.test.json` — is it needed?

Yes, I believe so since `vitest.config.ts` explicitly references it at `typecheck.tsconfig: './tsconfig.test.json'`.
The separate config excludes `src/app` from type-checking in tests since those files depend on the
Next.js build pipeline (app-router types, `.next/types`) that isn't available in the Vitest context.
Without it, `tsc` would error on app-router imports during `vitest --typecheck`.

Readiness Checklist

Author/Contributor

If documentation is needed for this change, has that been included in this pull request
run npm run format and fix any formatting issues that have been introduced
run npm run lint and fix any linting issues that have been introduced
run npm run test and run tests

Miablo · 2026-06-15T16:37:18Z

note: this should be run locally to confirm everything is working

wrslatz · 2026-06-16T11:50:28Z

    repository: Repository
  }>(getBranchProtectionRulesetGQL, {
-    owner: context.payload.repository.owner.login,
+    owner: context.payload.repository.owner!.login,


This case isn't just logging, so may need better error handling unless we're strongly confident this will always be defined

Could potentially make a utility function that handles the value being undefined and reuse that across the uses in the file

updated this -- can you take a look?

wrslatz · 2026-06-16T11:50:36Z

    branch: pattern,
    enforce_admins: true,
-    owner: context.payload.repository.owner.login,
+    owner: context.payload.repository.owner!.login,


updated -- can you take a look?

wrslatz · 2026-06-16T11:55:41Z

@@ -0,0 +1,12 @@
+{
+  "extends": "./tsconfig.json",


Is separate tsconfig needed? As part of #435 I updated tsconfig to include tests. Build only needs a separate tsconfig to adjust the default settings, but does test also need that? If not, I would revert this change.

fixed / removed!

riley-kohler

I'm still doing further testing but ran into some initial issues that were causing the application to break that I suggested fixes for.

Co-authored-by: Riley Kohler <code@rileykohler.com> Signed-off-by: Mio Diaz <themio@themioshow.com>

Co-authored-by: Will Slattum <wrslatz@gmail.com> Signed-off-by: Mio Diaz <themio@themioshow.com>

@ts-expect-error

- rules.ts: replace owner\!.login with owner?.login in log calls; add explicit undefined guard + throw in createBranchProtectionRuleset and createBranchProtectionREST where undefined would cause a runtime error - webhooks.ts: remove tslog custom logger; Probot v14 uses pino internally and is incompatible with tslog custom log adapters - controller.ts: replace @ts-expect-error suppressed custom-property calls with the correctly-typed octokit 5 method names (customPropertiesForReposGetRepositoryValues, customPropertiesForReposGetOrganizationDefinitions, customPropertiesForReposCreateOrUpdateOrganizationDefinition) Co-Authored-By: Claude Code

- listMirrorsHandler: return { mirrors, mirrorDeletionEnabled } shape added in upstream main - deleteMirrorHandler: add DISABLE_MIRROR_DELETION early guard added in upstream main Co-Authored-By: Claude Code

…nflicts Co-Authored-By: Claude Code

- Update .gitignore to use tsconfig.tsbuildinfo instead of *.tsbuildinfo - Add mirrorDeletionEnabled flag and Tooltip to fork page delete action - Remove as any casts from DataTable in page.tsx Co-Authored-By: Claude Code

Miablo · 2026-06-22T23:25:05Z

Found Error:

  src/app/[organizationId]/forks/[forkId]/page.tsx:571
  Type 'unknown[]' is not assignable to type 'UniqueRow[]'

Cause:
The backend fetches the list of mirrors from GitHub. When we upgraded the octokit library (v5), we told TypeScript that this list contains items of type unknown. The mirrors table component (DataTable) refuses to accept rows it knows nothing about — it needs to know each row has fields like name, html_url, etc. So the build stopped and complained that an unknown[] can't be used where a real, known row type (UniqueRow[]) is expected.

Fix:
Told TypeScript the actual shape of the data instead of unknown by deriving the real type straight from octokit's GitHub search response:

type SearchRepo = Awaited<ReturnType<Octokit['rest']['search']['repos']>>['data']['items'][number]
// ...
(response: { data: SearchRepo[] }) => response.data,

wrslatz

🚢, assuming manual testing looks good

wrslatz · 2026-06-22T23:51:53Z

-    },
-  }),
+// Probot v14 requires a pino logger so custom logging has been removed
+// In the future it is worth considering replacing tslog with pino entirely


Yeah, we should file an issue to track this

Miablo added 4 commits June 11, 2026 16:53

chore: upgrade octokit to v5 and probot to 14.3.2

0215d68

chore: update deps due to next-auth dep issue

49eb948

chore: update deps due to next-auth dep issue

7c80e6d

chore: add comments to files for as any

7376e4d

Miablo self-assigned this Jun 15, 2026

Miablo changed the title ~~Another miablo octokit~~ chore: upgrade octokit to v5 and probot to v14 Jun 15, 2026

chore: fix lint issues

b5c8e84

github-actions Bot added the maintenance label Jun 15, 2026

Miablo marked this pull request as ready for review June 15, 2026 16:35

Miablo requested review from a team as code owners June 15, 2026 16:35

Miablo mentioned this pull request Jun 15, 2026

Remove @ts-expect-error on custom properties API once octokit types are updated #485

Open

wrslatz reviewed Jun 16, 2026

View reviewed changes

riley-kohler requested changes Jun 16, 2026

View reviewed changes

Comment thread src/server/repos/controller.ts Outdated

Comment thread src/server/repos/controller.ts Outdated

Comment thread src/server/repos/controller.ts Outdated

Comment thread src/pages/api/webhooks.ts

Comment thread src/pages/api/webhooks.ts

Comment thread src/pages/api/webhooks.ts

Miablo and others added 5 commits June 18, 2026 22:12

Update controller.ts

ce95f23

Co-authored-by: Riley Kohler <code@rileykohler.com> Signed-off-by: Mio Diaz <themio@themioshow.com>

Update controller.ts

3e50d3d

Co-authored-by: Riley Kohler <code@rileykohler.com> Signed-off-by: Mio Diaz <themio@themioshow.com>

Update controller.ts

458ae2a

Co-authored-by: Riley Kohler <code@rileykohler.com> Signed-off-by: Mio Diaz <themio@themioshow.com>

Update webhooks.ts

dc021f5

Co-authored-by: Riley Kohler <code@rileykohler.com> Signed-off-by: Mio Diaz <themio@themioshow.com>

Update webhooks.ts

d654302

Co-authored-by: Riley Kohler <code@rileykohler.com> Signed-off-by: Mio Diaz <themio@themioshow.com>

spork-prod Bot force-pushed the another-miablo-octokit branch from 0948a0e to d654302 Compare June 19, 2026 02:13

Miablo and others added 3 commits June 18, 2026 22:13

Update rules.ts

04c340b

Co-authored-by: Will Slattum <wrslatz@gmail.com> Signed-off-by: Mio Diaz <themio@themioshow.com>

Update rules.ts

cd8e60c

Co-authored-by: Will Slattum <wrslatz@gmail.com> Signed-off-by: Mio Diaz <themio@themioshow.com>

Update rules.ts

7eafc0c

Co-authored-by: Will Slattum <wrslatz@gmail.com> Signed-off-by: Mio Diaz <themio@themioshow.com>

riley-kohler mentioned this pull request Jun 22, 2026

chore(deps): bump the npm_and_yarn group across 1 directory with 3 updates #488

Closed

Miablo added 5 commits June 22, 2026 12:56

chore: merge upstream main changes into controller.ts

4dd57dc

- listMirrorsHandler: return { mirrors, mirrorDeletionEnabled } shape added in upstream main - deleteMirrorHandler: add DISABLE_MIRROR_DELETION early guard added in upstream main Co-Authored-By: Claude Code

chore: merge main into feat/update-octokit-review-fixes to resolve co…

0404845

…nflicts Co-Authored-By: Claude Code

chore: sync upstream non-version changes to resolve PR conflicts

666ab93

- Update .gitignore to use tsconfig.tsbuildinfo instead of *.tsbuildinfo - Add mirrorDeletionEnabled flag and Tooltip to fork page delete action - Remove as any casts from DataTable in page.tsx Co-Authored-By: Claude Code

Merge branch 'main' into another-miablo-octokit

3ceb352

Miablo added 2 commits June 22, 2026 19:13

chore: fix merge conflicts and tests

f2d9d4c

chore: fix unknown type err

8756e3a

chore: remove extra tsconfig

f801119

Miablo requested review from riley-kohler and wrslatz June 22, 2026 23:30

wrslatz approved these changes Jun 22, 2026

View reviewed changes

Conversation

Miablo commented Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pull Request

Proposed Changes

Type workarounds

PR #477 Follow-ups

useForks.tsx:19 — satisfies over as

forks/[forkId]/page.tsx:570 — satisfies over as

controller.ts:37 — tracking issue

tsconfig.test.json — is it needed?

Readiness Checklist

Author/Contributor

Uh oh!

Miablo commented Jun 15, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

riley-kohler left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Miablo commented Jun 22, 2026

Uh oh!

wrslatz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Miablo commented Jun 15, 2026 •

edited

Loading

`useForks.tsx:19` — `satisfies` over `as`

`forks/[forkId]/page.tsx:570` — `satisfies` over `as`

`controller.ts:37` — tracking issue

`tsconfig.test.json` — is it needed?