Migrate custom types to shared-schemas (#17)

[misran3]

Closes #17

Summary

Migrates custom type definitions to use @insforge/shared-schemas types where equivalents exist:

• ✅ CreateDeploymentResponse: Migrated to shared-schemas re-export
• ✅ StartDeploymentRequest: Migrated to shared-schemas re-export
• ✅ SiteDeployment → DeploymentSchema: Updated consuming files (deploy.ts, status.ts) with proper field mappings

Changes

Type Migrations

• Added CreateDeploymentResponse, StartDeploymentRequest, and DeploymentSchema to shared-schemas re-exports in types.ts
• Removed duplicate custom interfaces from types.ts
• Updated FunctionResponse to use FunctionSchema from shared-schemas for the inner function property

File Updates

• deploy.ts: Updated type annotations, fixed error handling to read from metadata.error.errorMessage, removed deploymentUrl field usage (only url exists in API), uses typed status enum
• status.ts: Updated type assertion and field accesses to match DeploymentSchema structure

Test Plan

• TypeScript compilation passes (npm run build)
• Type checking passes (npx tsc --noEmit)
• Linting passes (npm run lint)
• No breaking changes to consuming code

Summary by CodeRabbit

• Refactor
  • Standardized deployment type references for consistency across the deployment workflow.
  • Simplified deployment URL resolution and error message extraction logic.
  • Consolidated deployment-related type definitions to use shared schema package.

[coderabbitai]

Walkthrough

This PR consolidates deployment-related types by removing local type definitions from src/types.ts and re-exporting them from the shared-schemas package. Related deployment command files are updated to use DeploymentSchema instead of SiteDeployment, with corresponding updates to error extraction and URL determination logic.

Changes

Cohort / File(s)	Summary
Type consolidation src/types.ts	Removed local type declarations for CreateDeploymentResponse, SiteDeployment, and StartDeploymentRequest. Added re-exports of these types plus DeploymentSchema from @insforge/shared-schemas package.
Deployment command updates src/commands/deployments/deploy.ts, src/commands/deployments/status.ts	Updated imports and type usages from SiteDeployment to DeploymentSchema. Modified error handling to extract from deployment.metadata?.error.errorMessage. Simplified URL determination to use deployment.url directly without fallback logic.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• Chore/data schema #10: Overlapping type consolidation effort—both PRs replace locally-defined deployment types with shared-schema types, specifically transitioning SiteDeployment to DeploymentSchema across similar command handling code.

Poem

🐰 Types unified, shared at last,
Local schemas now a thing of the past,
Deployments dance with schemas new,
Error messages and URLs shining through! 🚀

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: migrating custom types to shared-schemas equivalents, which is reflected across all modified files.
Linked Issues check	✅ Passed	The PR successfully migrates CreateDeploymentResponse, StartDeploymentRequest, and SiteDeployment to DeploymentSchema from shared-schemas, directly addressing the objective in issue #17.
Out of Scope Changes check	✅ Passed	All changes are directly scoped to migrating custom types to shared-schemas; error handling and field access updates are necessary adjustments for schema compatibility.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

📝 Coding Plan

• Generate coding plan for human review comments

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Tip

CodeRabbit can use your project's `biome` configuration to improve the quality of JS/TS/CSS/JSON code reviews.

Add a configuration file to your project to customize how CodeRabbit runs biome.

[coderabbitai]

🧹 Nitpick comments (1)

src/commands/deployments/status.ts (1)

41-41: Extract deployment error parsing into a local variable/helper.

This inline cast chain is hard to scan and maintain; pulling it into named variables will make this branch easier to read and keep aligned with deployment polling logic.

♻️ Proposed refactor

         if (json) {
           outputJson(d);
         } else {
+          const metadata = d.metadata as { error?: { errorMessage?: string } } | null;
+          const hasError = Boolean(metadata?.error);
+          const errorMessage = metadata?.error?.errorMessage ?? 'Unknown error';
+
           outputTable(
             ['Field', 'Value'],
             [
               ['ID', d.id],
               ['Status', d.status],
               ['Provider', d.provider ?? '-'],
               ['Provider ID', d.providerDeploymentId ?? '-'],
               ['URL', d.url ?? '-'],
               ['Created', new Date(d.createdAt).toLocaleString()],
               ['Updated', new Date(d.updatedAt).toLocaleString()],
-              ...((d.metadata as Record<string, unknown> | null)?.error ? [['Error', ((d.metadata as Record<string, unknown>).error as { errorMessage?: string })?.errorMessage ?? 'Unknown error']] : []),
+              ...(hasError ? [['Error', errorMessage]] : []),
             ],
           );
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/deployments/status.ts` at line 41, The inline cast chain reading
d.metadata should be extracted into a named local variable or small helper
(e.g., getDeploymentErrorMessage or parseDeploymentError) so the branch is
easier to read and reuse with the deployment polling logic; inside status.ts
create a const metadata = d.metadata as Record<string, unknown> | null, then
const err = metadata?.error as { errorMessage?: string } | undefined and const
errorMessage = err?.errorMessage ?? 'Unknown error', and replace the inline
chain with a reference to that errorMessage (or call the helper) where the Error
row is built and in any polling code that needs the same parsing.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/commands/deployments/status.ts`:
- Line 41: The inline cast chain reading d.metadata should be extracted into a
named local variable or small helper (e.g., getDeploymentErrorMessage or
parseDeploymentError) so the branch is easier to read and reuse with the
deployment polling logic; inside status.ts create a const metadata = d.metadata
as Record<string, unknown> | null, then const err = metadata?.error as {
errorMessage?: string } | undefined and const errorMessage = err?.errorMessage
?? 'Unknown error', and replace the inline chain with a reference to that
errorMessage (or call the helper) where the Error row is built and in any
polling code that needs the same parsing.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ca3ad957-5773-4bb5-a063-55266a87dab4

📥 Commits

Reviewing files that changed from the base of the PR and between 9c3bebc and f473aae.

📒 Files selected for processing (3)

• src/commands/deployments/deploy.ts
• src/commands/deployments/status.ts
• src/types.ts