Repository navigation
refactor: fix types in deploy command and its utils - #8599
Conversation
|
Important Review skippedReview was skipped as selected files did not have any reviewable changes. ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (18)
🔗 Linked repositories identifiedCodeRabbit considers these linked repositories for cross-repo context during reviews:
💤 Files with no reviewable changes (1)
Included review availability: This review used your included allowance. 9 included reviews remain after this review. Your included PR review attempts over the past 7 days set your current allowance at 10 reviews per hour. Your free on-demand review promotion remains active until October 9, 2026 at 6:00 PM UTC. 📝 SummarySummary by CodeRabbit
WalkthroughThe deploy pipeline now uses more explicit types for configuration, files, API responses, and deploy results. The changes add support for inline upload content, type deploy polling results, and update deploy command handling. ESLint suppression counts are also revised, and related test casts and suppression comments are removed. Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~25 minutes Change: Refactor Suggested reviewers: Merge Risk: ⚪ Minimal · up to The deploy typing changes appear ready to merge after normal checks; no concrete deployment regression remains identified. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
commit: |
84e611d to
fa00059
Compare
| case 'ready': { | ||
| deploy = siteDeploy | ||
| return true | ||
| return pWaitFor.resolveWith(siteDeploy) |
There was a problem hiding this comment.
Technically this is an exception to the "no changes to runtime code" rule for this PR, but this is really the same behaviour and it unlocks typing this properly.
Replace the `$TSFixMe`/`any` parameters and `@ts-expect-error` markers in the deploy command and `src/utils/deploy/` with real types: Remaining gaps in upstream typings are marked with specific FIXME casts or suppressions. Runtime behaviour is unchanged.
fa00059 to
74f1ee5
Compare
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
#### Summary Batch 1 of 3 of follow-ups to #8599. Out of an abundance of caution, that PR was kept purely focused on type changes. - Create deploys through a single helper, instead of duplicating across `--build` and `--no-build` - Behaviour change (technically): with `--build`, a deploy response without an `id` no longer falls back to an empty-string deploy ID; the deploy ID is passed through as returned by the API, matching the `--no-build` path. ✅ Verified not possible in backend code. - Use optional chaining where we now can. - Behaviour change (technically): a non-object `published_deploy` (for example a function) with a truthy `locked` property now counts as locked. ✅ Verified not possible in backend code. - Remove optional chaining now revealed to be unnecessary. - Behaviour change (technically) if the types are wrong. ✅ Verified not possible in build and backend code.
Summary
Replace the
$TSFixMe/anyparameters and@ts-expect-errormarkers in the deploy command andsrc/utils/deploy/with real types.Remaining gaps in upstream package types are marked with specific FIXME casts or suppressions.
Runtime behaviour is aggressively unchanged in an effort to keep this PR entirely about fixing/adding types.
any$TSFixMe(any)@ts-expect-erroras)