chore: migrate deployment types to shared-schemas (#17)

[AbdulWasih05]

Closes #17

What

Migrates custom deployment type definitions in the CLI to use shared-schemas from @insforge/shared-schemas, replacing local interfaces with canonical types.

Why

Issue #17 asks to unify custom types to shared-schemas defined types. Local types were duplicating definitions already available in shared-schemas, and in the case of DeploymentMetadata, the local type had stale field names causing the metadata command to silently display nulls.

How

Types migrated (4):

• CreateDeploymentResponse -- identical structure, drop-in replacement
• StartDeploymentRequest -- identical structure, drop-in replacement
• SiteDeployment → DeploymentSchema -- status enum normalized to uppercase, error extraction moved from top-level error field to metadata.error.errorMessage, removed stale deploymentUrl field
• DeploymentMetadata → DeploymentMetadataResponse -- fixes a bug where the CLI used domain/slug/deploymentUrl but the API returns defaultDomainUrl/customDomainUrl

Types kept local (2):

• FunctionResponse / FunctionDeploymentResult -- these exist in shared-schemas source but the published npm package does not export them yet. Can be migrated once published.

Other changes:

• Added getDeploymentError() helper in src/lib/errors.ts for clean error extraction from DeploymentSchema.metadata, reused in deploy.ts and status.ts
• Bumped @insforge/shared-schemas from ^1.1.43 to ^1.1.44 (required for DeploymentMetadataResponse export)

How to Test

1. insforge deployments metadata -- displays Default Domain URL and Custom Domain URL fields
2. insforge deployments status <id> -- displays URL (single field, no more deploymentUrl fallback) and extracts errors from metadata.error.errorMessage

Summary by CodeRabbit

• Bug Fixes

  • Improved deployment error messages by surfacing metadata-derived errors.
  • More reliable deployment status detection and URL handling; live URLs shown only for ready deployments.
  • Deployment status and metadata display adjusted for clearer, consistent output.

• Chores

  • Bumped shared schema dependency version.

• Refactor

  • Centralized deployment-related types and utilities for consistency.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: caed0769-bac4-4eaf-89ff-9214469f5a5f

📥 Commits

Reviewing files that changed from the base of the PR and between c9bd799 and 21c6012.

📒 Files selected for processing (1)

• src/commands/deployments/deploy.ts

---

Walkthrough

This PR bumps @insforge/shared-schemas and replaces local deployment types with shared-schema types, updates commands to use DeploymentSchema, normalizes status checks to uppercase, centralizes error extraction via getDeploymentError, and adjusts URL/metadata handling in deployment commands.

Changes

Cohort / File(s)	Summary
Dependency package.json	Bumped @insforge/shared-schemas from ^1.1.43 to ^1.1.44.
Type exports src/types.ts	Removed local deployment interfaces; re-exported CreateDeploymentResponse, StartDeploymentRequest, DeploymentSchema, DeploymentMetadataResponse from @insforge/shared-schemas.
Deploy command src/commands/deployments/deploy.ts	Switched deployment typing to `DeploymentSchema
Metadata command src/commands/deployments/metadata.ts	Cast response to DeploymentMetadataResponse; non-JSON table now shows Default Domain URL / Custom Domain URL instead of previous domain/slug/deploymentUrl fields.
Status command src/commands/deployments/status.ts	Fetches deployment as DeploymentSchema; uses getDeploymentError(metadata) for error display; shows d.url (no fallback to d.deploymentUrl).
Error utilities src/lib/errors.ts	Added exported getDeploymentError(metadata) which safely extracts metadata.error.errorMessage or returns null.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• Chore/data schema #10: Also migrates local deployment types to @insforge/shared-schemas and updates command usages to the shared types.
• Feat/metadata #9: Previously added the @insforge/shared-schemas dependency that this PR updates and consumes.

Poem

🐰 I hopped through types both old and new,
Swapped local shapes for schemas true.
Statuses shouted in uppercase cheer,
Errors gathered from metadata near—
A tiny rabbit applauds this view! 🥕

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 40.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 clearly summarizes the main change: migrating deployment types to shared-schemas, which is the primary objective of the PR.
Linked Issues check	✅ Passed	The PR successfully replaces custom deployment type definitions with canonical types from @insforge/shared-schemas, directly addressing issue #17's requirement to unify API types.
Out of Scope Changes check	✅ Passed	All changes are directly related to the type migration objective: updating type references, adding error extraction helper, and normalizing deployment status handling align with issue #17.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.}

[jwfing]

[P1] Keep polling compatible with lowercase deployment statuses — src/commands/deployments/deploy.ts:130-146
If the OSS API still returns the lowercase statuses that the previous code explicitly handled (ready, error, canceled), this loop no longer recognizes successful or terminal deployments. In that case insforge deployments deploy will spin until the 2-minute timeout even though the deployment has already finished, and failed deployments will be reported as timeouts instead of surfacing the real error.

Suggestion: convert status to UpperCase then compare.

[AbdulWasih05]

Hey @jwfing, Status is now normalized with .toUpperCase() before comparison in both the polling loop and the final isReady check.