Skip to content

Update SDK documentation for new type system #666

@nickna

Description

@nickna

Overview

Part of #658 - Document the new type system and provide migration guidance for developers.

Dependencies

Should be done after most refactoring is complete to ensure accurate documentation.

Documentation Needed

1. Architecture Documentation

  • Explain why we use generated types as source of truth
  • Document the type generation process
  • Show the relationship between OpenAPI spec and TypeScript types

2. Developer Guide

  • How to work with generated types
  • When to extend vs alias types
  • Common patterns and anti-patterns
  • How to handle client-only types

3. Migration Guide

  • Breaking changes list
  • Step-by-step migration for consumers
  • Common migration issues and solutions
  • Type compatibility reference

4. Maintenance Guide

  • How to regenerate types
  • Adding new type validations
  • Troubleshooting type issues
  • CI/CD type checking process

Documentation Structure

docs/
├── sdk/
│   ├── architecture/
│   │   └── type-system.md
│   ├── guides/
│   │   ├── working-with-types.md
│   │   ├── migration-guide.md
│   │   └── type-patterns.md
│   └── reference/
│       ├── generated-types.md
│       └── type-mappings.md

Example Content

Type System Overview

# SDK Type System

The Admin SDK uses generated TypeScript types from the OpenAPI specification as the single source of truth.

## Why Generated Types?

1. **Consistency**: API and SDK types always match
2. **Automation**: No manual updates needed
3. **Type Safety**: Catches API changes at compile time

## Type Patterns

### Simple Alias
\`\`\`typescript
export type ProviderCredentialDto = components['schemas']['ConduitLLM.Configuration.DTOs.ProviderCredentialDto'];
\`\`\`

### Extended Types
\`\`\`typescript
interface ProviderWithHealth extends ProviderCredentialDto {
  healthStatus?: 'healthy' | 'unhealthy';
}
\`\`\`

Definition of Done

  • All documentation sections complete
  • Code examples tested and working
  • Migration guide validated by team
  • Documentation reviewed for clarity
  • Published to documentation site
  • Team trained on new patterns

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions