chore: Fix all 246 TypeScript errors in UI#702
Conversation
…ents - Added a new `typecheck` script in `package.json` for better type checking in the UI workspace. - Refactored several components to remove unnecessary type assertions and improve type safety, particularly in `new-project-modal.tsx`, `edit-project-dialog.tsx`, and `task-progress-panel.tsx`. - Updated event handling in `git-diff-panel.tsx` to use async functions for better error handling. - Improved type definitions in various files, including `setup-view` and `electron.ts`, to ensure consistent usage of types across the codebase. - Cleaned up global type definitions for better clarity and maintainability. These changes aim to streamline the development process and reduce potential runtime errors.
- Extended SetupAPI interface with 20+ missing methods for Cursor, Codex, OpenCode, Gemini, and Copilot CLI integrations - Fixed WorktreeInfo type to include isCurrent and hasWorktree fields - Added null checks for optional API properties across all hooks - Fixed Feature type conflicts between @automaker/types and local definitions - Added missing CLI status hooks for all providers - Fixed type mismatches in mutation callbacks and event handlers - Removed dead code referencing non-existent GlobalSettings properties - Updated mock implementations in electron.ts for all new API methods Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. 📝 WalkthroughWalkthroughAdds extensive TypeScript typings and runtime guards across the UI: replaces permissive Changes
Sequence Diagram(s)(Skipped — changes are broad typing and guards without introducing a single new multi-component control flow to visualize.) Estimated code review effort🎯 4 (Complex) | ⏱️ ~55 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
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 |
Summary of ChangesHello @Shironex, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request primarily focuses on a large-scale refactor to enhance the UI's type safety and strictness. It cleans up numerous existing TypeScript errors, solidifies API interfaces, and ensures data structures are more accurately represented, leading to a more reliable and maintainable codebase. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This is a substantial and valuable pull request that significantly improves the TypeScript type safety across the UI codebase. The effort to eliminate any types and introduce stricter typing is commendable and will certainly enhance maintainability and reduce potential runtime errors. The changes are well-executed and demonstrate a good understanding of the codebase's types. I've identified a couple of minor areas for improvement and one potential bug, but overall, this is excellent work.
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
apps/ui/src/components/views/board-view/dialogs/pull-resolve-conflicts-dialog.tsx (1)
41-46: Await asynconConfirmto avoid unhandled failures.
WithonConfirmnow possibly async, the dialog closes before the operation finishes and any rejection is unhandled. Consider awaiting and surfacing errors.✅ Suggested fix
- const handleConfirm = () => { + const handleConfirm = async () => { if (!worktree || !selectedBranch) return; - onConfirm(worktree, selectedBranch); - onOpenChange(false); + try { + await onConfirm(worktree, selectedBranch); + onOpenChange(false); + } catch (err) { + logger.error('Failed to start pull/resolve', err); + toast.error('Failed to start pull/resolve'); + } };apps/ui/src/hooks/use-settings-sync.ts (1)
548-548: The double type assertion masks an incomplete API response type definition.The
as unknown as GlobalSettingscast at line 548 (and also in use-settings-migration.ts:493 and use-settings.ts:35) suppresses TypeScript checks because the actual API response type in http-api-client.ts (lines 2402–2430) is narrower thanGlobalSettings. The API type omits fields likesidebarStyle,collapsedNavSections,cursorDefaultModel,enabledOpencodeModels, and many others that the code attempts to use after the assertion.The code does perform some validation—model ID migration and sanitization using functions like
migrateCursorModelIds()and validation against available model sets—but this occurs after the assertion, so it doesn't prevent the type mismatch.To improve type safety, either:
- Expand the API response type in http-api-client.ts to match all fields actually returned by the server, or
- Add schema-based runtime validation (e.g., Zod) to validate the entire response shape at the API boundary.
Also note: Line 682 contains a separate double assertion (
theme as unknown as ThemeMode) which should be addressed separately.apps/ui/src/store/app-store.ts (1)
680-688: Worktree fieldsisCurrentandhasWorktreeare missing from backend payload in the sync flow.The backend
WorktreeInfotype (from React Query hook) does not includeisCurrentorhasWorktreefields, butsetWorktreesin the store requires them. Whenuse-worktrees.tssyncs backend worktrees directly to the store at line 34, these required fields will be undefined at runtime.Manual creations in graph-view-page.tsx and board-view.tsx explicitly provide both fields, but the backend sync path does not. Either:
- Backend should populate these fields in the API response, or
- The sync in
use-worktrees.tsshould enrich the data before callingsetWorktrees, or- These fields should be optional in the store schema if they're computed locally
🤖 Fix all issues with AI agents
In `@apps/ui/src/components/views/settings-view/cli-status/claude-cli-status.tsx`:
- Around line 92-98: The code calls api.setup.authClaude without ensuring
authClaude exists; add a guard mirroring the deauthClaude check by verifying
api.setup && typeof api.setup.authClaude === 'function' before awaiting
api.setup.authClaude(), and if missing show the same toast.error (e.g.,
'Authentication Failed' with description 'Setup API is not available') and
return; update the block that currently checks only api.setup to perform this
combined check to prevent runtime exceptions when authClaude is undefined.
In `@apps/ui/src/components/views/settings-view/cli-status/cursor-cli-status.tsx`:
- Around line 211-222: The code assumes getElectronAPI() always returns an
object and directly dereferences api.setup; change the guard to first
optional-chain on the API itself (use (getElectronAPI()?.setup ...) or check api
!== undefined) before accessing .setup so you don't throw when running outside
Electron; update the auth check around getElectronAPI, api.setup and the
authCursor extraction in cursor-cli-status.tsx (also apply same
optional-chaining/undefined check to the similar block referenced at lines
246-257) and keep the existing toast.error fallback when authCursor is missing.
In `@apps/ui/src/hooks/mutations/use-auto-mode-mutations.ts`:
- Around line 348-351: The mutation in useStartAutoMode (inside mutationFn)
passes String(maxConcurrency) as the second argument to api.autoMode.start,
which treats it as branchName and leaves maxConcurrency undefined; update the
call to pass branchName (or undefined/null) as the second parameter and the
numeric maxConcurrency as the third — e.g., call api.autoMode.start(projectPath,
undefined, maxConcurrency ?? undefined) or Number(maxConcurrency) — so that
api.autoMode.start receives (projectPath, branchName?, maxConcurrency?) in the
correct order.
In `@apps/ui/src/hooks/queries/use-cli-status.ts`:
- Around line 58-75: The hook useApiKeysStatus currently returns the raw result
from api.setup.getApiKeys without validating its success flag; mirror the other
hooks (e.g., useClaudeCliStatus/useGitHubCliStatus) by checking result.success
after calling getElectronAPI() and api.setup.getApiKeys, and if result.success
is false throw a new Error('Failed to fetch API keys') before returning the
result so callers only receive successful responses.
♻️ Duplicate comments (7)
apps/ui/src/hooks/queries/use-settings.ts (4)
52-60: Same API guard issue as above.
Apply the sameapi?.settingscheck here.
76-79: Same API guard issue as above.
Apply the sameapi?.settingscheck here.
96-99: Same API guard issue as above.
Apply the sameapi?.settingscheck here.
125-128: Same API guard issue as above.
Apply the sameapi?.settingscheck here.apps/ui/src/components/views/setup-view/steps/providers-setup-step.tsx (3)
1007-1019: Same OpenCode command fallback concern as above.This repeats the same potential regression discussed in
OpencodeSetupStep; if the Electron API still exposesinstallCommand/loginCommand, consider preserving those values with a fallback.
1861-1876: Duplicate Codex auth-method guard.Same refactor suggestion as the CodexContent block: centralize the guard to avoid drift.
1890-1902: Duplicate OpenCode command fallback concern.Same issue as the OpenCode blocks above; ensure API-provided commands aren’t dropped unless the contract guarantees they’re gone.
🧹 Nitpick comments (19)
apps/ui/src/hooks/use-settings-migration.ts (1)
671-676: Consider extracting the cast to reduce duplication.The double-cast pattern is valid for accessing properties not declared in the type, but it's duplicated. Extracting to a variable improves readability and reduces repetition.
♻️ Suggested refactor
+ const settingsRecord = settings as unknown as Record<string, unknown>; + if (settingsRecord.autoModeByWorktree) { + const persistedSettings = settingsRecord.autoModeByWorktree as Record< - if ((settings as unknown as Record<string, unknown>).autoModeByWorktree) { - const persistedSettings = (settings as unknown as Record<string, unknown>) - .autoModeByWorktree as Record< string, { maxConcurrency?: number; branchName?: string | null } >;Ideally, if
autoModeByWorktreeis a legitimate property that should be persisted, consider adding it to theGlobalSettingstype in@automaker/typesto eliminate the need for type assertions entirely.apps/ui/src/components/views/settings-view/providers/cursor-permissions-section.tsx (1)
174-176: Type assertion may mask future runtime issues.The
profile.id as 'strict' | 'development'assertion bypasses type safety. IfavailableProfilesever contains profiles with different IDs, this would silently pass invalid values toonApplyProfile.Consider either:
- Narrowing the
profile.idtype inPermissionsDatato'strict' | 'development'- Adding a runtime guard before calling the handler
♻️ Optional: Add runtime validation
onClick={() => - onApplyProfile(profile.id as 'strict' | 'development', 'global') + { + if (profile.id === 'strict' || profile.id === 'development') { + onApplyProfile(profile.id, 'global'); + } + } }apps/ui/src/hooks/use-query-invalidation.ts (1)
326-329: Consider a type guard for better runtime safety.The
as StreamEventcast works but provides no runtime validation. The defensive'sessionId' in eventcheck on line 329 helps, but a type guard would catch malformed events earlier.Optional: Add a type guard for StreamEvent validation
function isStreamEvent(data: unknown): data is StreamEvent { return ( typeof data === 'object' && data !== null && 'type' in data && 'sessionId' in data && typeof (data as StreamEvent).sessionId === 'string' ); }Then use it:
const unsubscribe = api.agent.onStream((data: unknown) => { - const event = data as StreamEvent; - // Only handle events for the current session - if ('sessionId' in event && event.sessionId !== sessionId) return; + if (!isStreamEvent(data)) return; + // Only handle events for the current session + if (data.sessionId !== sessionId) return;apps/ui/src/components/views/board-view/shared/model-selector.tsx (2)
42-43: Avoid@ts-expect-errorby narrowingcodexCliStatus(or fixing its store type).
IfcodexCliStatustruly hasauth, prefer a type guard (or update the store type) and remove the suppression.♻️ Suggested local guard to drop the suppression
- // `@ts-expect-error` - codexCliStatus uses CliStatus type but should use CodexCliStatus which has auth - const isCodexAvailable = codexCliStatus?.installed && codexCliStatus?.auth?.authenticated; + const hasCodexAuth = ( + status: typeof codexCliStatus + ): status is typeof codexCliStatus & { auth: { authenticated?: boolean } } => + !!status && typeof status === 'object' && 'auth' in status; + + const isCodexAvailable = + hasCodexAuth(codexCliStatus) && + !!codexCliStatus.installed && + !!codexCliStatus.auth?.authenticated;
76-79: Normalize enabled Cursor model IDs once to avoid unsafe casts.
Canonicalize tocursor-*and compare withoutas CursorModelId.♻️ Suggested normalization
- const filteredCursorModels = CURSOR_MODELS.filter((model) => { - // enabledCursorModels stores CursorModelIds which may or may not have "cursor-" prefix - // (e.g., 'auto', 'sonnet-4.5' without prefix, but 'cursor-gpt-5.2' with prefix) - // CURSOR_MODELS always has the "cursor-" prefix added in model-constants.ts - // Check both the full ID (for GPT models) and the unprefixed version (for non-GPT models) - const unprefixedId = model.id.startsWith('cursor-') ? model.id.slice(7) : model.id; - return ( - enabledCursorModels.includes(model.id as CursorModelId) || - enabledCursorModels.includes(unprefixedId as CursorModelId) - ); - }); + const canonicalEnabledCursorModels = new Set( + enabledCursorModels.map((id) => (id.startsWith('cursor-') ? id : `cursor-${id}`)) + ); + + const filteredCursorModels = CURSOR_MODELS.filter((model) => + canonicalEnabledCursorModels.has(model.id) + );apps/ui/src/hooks/use-settings-sync.ts (1)
357-362: The 50ms delay is a fragile heuristic.The delay to wait for React render completion is well-documented but may be insufficient on slower devices or during heavy rendering. Consider using
requestIdleCallbackorqueueMicrotaskwith a fallback for more reliable scheduling.♻️ Alternative using requestIdleCallback
- // Wait for React to finish rendering after store hydration. - // Zustand's subscribe() fires during setState(), which happens BEFORE React's - // render completes. Use a small delay to ensure all pending state updates - // have propagated through the React tree before we read state. - await new Promise((resolve) => setTimeout(resolve, 50)); + // Wait for React to finish rendering after store hydration. + // Zustand's subscribe() fires during setState(), which happens BEFORE React's + // render completes. Use requestIdleCallback to wait until the browser is idle. + await new Promise<void>((resolve) => { + if ('requestIdleCallback' in window) { + window.requestIdleCallback(() => resolve(), { timeout: 100 }); + } else { + setTimeout(resolve, 50); + } + });apps/ui/src/components/views/setup-view/steps/providers-setup-step.tsx (1)
708-725: Prefer a shared CodexAuthMethod guard to avoid drift.You already export
CodexAuthMethodfromapps/ui/src/store/setup-store.ts. Duplicating the valid methods list here (and again incheckAllProviders) risks future mismatch. Consider extracting a single helper (or reusing the store type) for both sites.♻️ Example refactor (within this block)
- const validMethods = ['api_key_env', 'api_key', 'cli_authenticated', 'none'] as const; - type CodexAuthMethod = (typeof validMethods)[number]; - const method: CodexAuthMethod = validMethods.includes( - result.auth.method as CodexAuthMethod - ) - ? (result.auth.method as CodexAuthMethod) - : 'cli_authenticated'; + const method = coerceCodexAuthMethod(result.auth.method);You could define the helper once (near the top of this file) and reuse it:
import type { CodexAuthMethod } from '@/store/setup-store'; const CODEX_AUTH_METHODS: readonly CodexAuthMethod[] = [ 'api_key_env', 'api_key', 'cli_authenticated', 'none', ]; const coerceCodexAuthMethod = (value?: string): CodexAuthMethod => CODEX_AUTH_METHODS.includes(value as CodexAuthMethod) ? (value as CodexAuthMethod) : 'cli_authenticated';apps/ui/src/components/views/settings-view/providers/opencode-settings-tab.tsx (1)
57-58: Type cast works but masks a potential type mismatch.The cast
as typeof cliStatusData.auth & { error?: string }suggests the source type (cliStatusData.auth) is missing theerrorfield. SinceOpencodeAuthStatusalready includeserror?: string(peropencode-cli-status.tsx), consider updating the upstream type definition (likely the query hook's return type) to includeerrorinstead of casting here.This cast is acceptable as a workaround for this PR's scope, but tracking this for a future cleanup would improve type coherence.
apps/ui/src/components/ui/git-diff-panel.tsx (1)
482-490: Redundant async/await wrapper.The
async () => await loadDiffs()pattern is functionally equivalent to() => loadDiffs()since the promise result isn't being used. The extra async wrapper adds no error handling benefit here.However, this is a minor stylistic point and doesn't affect functionality.
Simplified handlers
- onClick={async () => await loadDiffs()} + onClick={() => loadDiffs()}Also applies to: 558-566
apps/ui/src/components/views/board-view/hooks/use-board-persistence.ts (1)
52-53: Redundant cast and potential type mismatch.Line 52 casts
result.featuretoFeature, and line 53 immediately recasts it toPartial<Feature>. The intermediate cast toFeatureis unnecessary since you're using it asPartial<Feature>anyway. More importantly,ApiFeaturemay lack required UI-specific fields (e.g.,stepsis requiredstring[]in UIFeaturebut optional inApiFeature), so casting directly toFeaturecould mask type errors.Suggested simplification
if (result.success && result.feature) { - const updatedFeature = result.feature as Feature; - updateFeature(updatedFeature.id, updatedFeature as Partial<Feature>); + const updatedFeature = result.feature; + updateFeature(updatedFeature.id, updatedFeature as Partial<Feature>);apps/ui/src/components/views/settings-view/providers/codex-settings-tab.tsx (1)
57-72: Consider extracting duplicated type definition and logic.The
getCodexStatustype definition and invocation pattern is duplicated between theuseEffect(lines 57-72) andhandleRefreshCodexCli(lines 116-130). This violates DRY and makes maintenance harder.Suggested extraction
+type GetCodexStatusFn = () => Promise<{ + success: boolean; + installed: boolean; + version?: string; + path?: string; + recommendation?: string; + installCommands?: { npm?: string; macos?: string; windows?: string }; + auth?: { + authenticated: boolean; + method: string; + hasApiKey?: boolean; + }; +}>; + +function getCodexStatusFn(api: ReturnType<typeof getElectronAPI>): GetCodexStatusFn | undefined { + return (api?.setup as Record<string, unknown> | undefined)?.getCodexStatus as GetCodexStatusFn | undefined; +}Then use
getCodexStatusFn(api)in both places.Also applies to: 116-130
apps/ui/src/components/views/board-view/hooks/use-board-features.ts (2)
188-192: InconsistentloadFeaturesbehavior between internal and external usage.The returned
loadFeatures(lines 188-192) usesqueryClient.invalidateQueries, while the internal event handlers (lines 112, 116) callloadFeatures()which references therefetchfunction fromuseFeatures(line 31). This inconsistency could cause confusion:
- Internal: calls
refetch()directly, returning fresh data- External callers: get
invalidateQueries(), which marks data staleConsider either using consistent behavior throughout, or renaming to clarify the distinction.
Option 1: Use consistent invalidation
+ const invalidateFeatures = useCallback(async () => { + await queryClient.invalidateQueries({ + queryKey: queryKeys.features.all(currentProject?.path ?? ''), + }); + }, [queryClient, currentProject?.path]); + // In event handlers, use: - loadFeatures(); + invalidateFeatures();
35-53: Unnecessary dependency inloadCategories.
loadFeaturesis included in the dependency array (line 53) but is not used within theloadCategoriesfunction body. This could cause unnecessary re-creation of the callback.Remove unused dependency
- }, [currentProject, loadFeatures]); + }, [currentProject]);apps/ui/src/components/views/graph-view-page.tsx (1)
152-177: Consider adding runtime validation for the event payload.Casting
unknowndirectly to the expected shape without runtime validation can lead to silent failures if the event structure changes. Consider using a type guard or at minimum checking for required properties before accessing them.🔧 Suggested improvement
const unsubscribe = api.backlogPlan.onEvent((data: unknown) => { - const event = data as { type: string; result?: BacklogPlanResult; error?: string }; + if (typeof data !== 'object' || data === null || !('type' in data)) { + logger.warn('Received malformed backlog plan event', { data }); + return; + } + const event = data as { type: string; result?: BacklogPlanResult; error?: string }; logger.debug('Backlog plan event received', {apps/ui/src/components/ui/task-progress-panel.tsx (1)
57-60: Consider improving the API result typing upstream.The cast
(result as { success: boolean; feature?: Feature })suggests theapi.features.getreturn type may need improvement in the Electron API types. The guard at line 58 makes the subsequent access safe.apps/ui/src/components/views/board-view/dialogs/agent-output-modal.tsx (1)
264-266: Consider adding type guard or validation before casting.The pattern of accepting
unknownand immediately casting toBacklogPlanEventis safe for type checking but provides no runtime protection if the API returns unexpected data. The null check on line 266 (if (!event?.type)) helps, but a type guard would be more robust.This is acceptable given the trusted internal API, but worth noting for future maintainability.
💡 Optional: Add a type guard for safer casting
function isBacklogPlanEvent(data: unknown): data is BacklogPlanEvent { return ( typeof data === 'object' && data !== null && 'type' in data && typeof (data as { type: unknown }).type === 'string' ); } // Then use: const unsubscribe = api.backlogPlan.onEvent((data: unknown) => { if (!isBacklogPlanEvent(data)) return; // data is now typed as BacklogPlanEvent // ... });apps/ui/src/types/electron.d.ts (1)
1445-1460: Redundant properties in ExtendedElectronAPI.Several properties in
ExtendedElectronAPIalready exist in the baseElectronAPI:
isElectron(line 566)getApiKey(line 569)These re-declarations are redundant since
ExtendedElectronAPI extends ElectronAPI.Additionally,
getPathhas a stricter type signature here ('documents' | 'home' | 'appData' | 'userData') compared to the base (string). This is valid TypeScript (narrowing), but consider whether this restriction is intentional or should be applied to the base interface.♻️ Remove redundant properties
export interface ExtendedElectronAPI extends ElectronAPI { - /** Runtime marker indicating Electron environment */ - isElectron?: boolean; /** Get the server URL (Electron-only) */ getServerUrl?: () => Promise<string>; - /** Get the API key (Electron-only) */ - getApiKey?: () => Promise<string | null>; /** Check if running in external server mode (Electron-only) */ isExternalServerMode?: () => Promise<boolean>; /** Get system paths (Electron-only) */ getPath?: (name: 'documents' | 'home' | 'appData' | 'userData') => Promise<string>; }apps/ui/src/types/global.d.ts (2)
58-64: Duplicate Window.electronAPI augmentation with electron.d.ts.This file augments
Window.electronAPIwith extended properties, butelectron.d.ts(lines 1462-1467) also declares a global Window augmentation usingExtendedElectronAPI. Having two separate augmentations for the same property can cause confusion and potential type conflicts.Consider consolidating the Window augmentation in one location. Since
electron.d.tsalready definesExtendedElectronAPIwith the same extended methods, this file could simply import and reference that type instead of inline re-declaring the extensions.♻️ Consolidate Window.electronAPI typing
-import type { ElectronAPI } from '../lib/electron'; +import type { ExtendedElectronAPI } from './electron'; declare global { interface Window { // ... mock properties ... /** * Electron API exposed via preload script */ - electronAPI?: ElectronAPI & { - isElectron?: boolean; - getServerUrl?: () => Promise<string>; - getApiKey?: () => Promise<string | null>; - isExternalServerMode?: () => Promise<boolean>; - getPath?: (name: 'documents' | 'home' | 'appData' | 'userData') => Promise<string>; - }; + electronAPI?: ExtendedElectronAPI; } }
14-28: Inconsistent export of interface types.
MockProjectis exported (line 23) whileMockContextFileis not. IfMockContextFileis also needed outside this file (e.g., in test utilities), consider exporting it for consistency.♻️ Export MockContextFile for consistency
/** * Mock context file data for testing */ -interface MockContextFile { +export interface MockContextFile { featureId: string; path: string; content: string; }
apps/ui/src/components/views/settings-view/cli-status/claude-cli-status.tsx
Outdated
Show resolved
Hide resolved
apps/ui/src/components/views/settings-view/cli-status/cursor-cli-status.tsx
Show resolved
Hide resolved
- Fix window.Electron to window.isElectron in http-api-client.ts - Use void operator instead of async/await for onClick handlers in git-diff-panel.tsx - Fix critical bug: correct parameter order in useStartAutoMode (maxConcurrency was passed as branchName) - Add error handling for getApiKeys() result in use-cli-status.ts - Add authClaude guard in claude-cli-status.tsx for consistency with deauthClaude - Add optional chaining on api object in cursor-cli-status.tsx Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
Summary
npm run typecheckin the UI workspaceSetupAPIinterface with 20+ missing methods for CLI integrationsWorktreeInfotype to include required fields (isCurrent,hasWorktree)Test plan
npm run typecheckpasses with 0 errorsnpm run build:packages && npm run buildsucceedsnpm run test:packages- 519 tests passnpm run test:server- 1415 tests pass🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes / Improvements
Refactor
Chores
✏️ Tip: You can customize this high-level summary in your review settings.