Skip to content

fix: empty spec names in schema generator #70

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ichung08 merged 3 commits into from
Dec 9, 2025
Merged

fix: empty spec names in schema generator #70

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
44884a4
fix: empty spec names in schema generator
ichung08 Dec 9, 2025
63789f5
fix: bugs
ichung08 Dec 9, 2025
3ce2cf3
test: add generator unit tests
ichung08 Dec 9, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 1 addition & 11 deletions epoch/openapi/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -379,11 +379,6 @@ The generator uses different naming strategies depending on whether schemas are
- Preserves the same name across all versions
- Example: `versionedapi.UpdateExampleRequest` in all version files

**When generating from scratch** (not found in base spec):
- **HEAD version**: Uses bare type name (e.g., `UserResponse`)
- **Versioned releases**: Uses type name + version suffix (e.g., `UserResponseV20240101`)
- Version suffix format: `V` + date without hyphens (e.g., `V20240101`)

**Unmanaged schemas** (in base spec but not in TypeRegistry):
- Preserved as-is in all versions
- Examples: `ErrorResponse`, `PaginationMeta`, common utility types
Expand All @@ -393,12 +388,8 @@ The generator uses different naming strategies depending on whether schemas are

**`SchemaNameMapper`**: Maps Go type names to OpenAPI schema names (useful for Swag integration with package prefixes)

**`ComponentNamePrefix`**: Adds prefix to version suffixes (e.g., `"Astro"` → `UserResponseAstroV20240101`)

**`OutputFormat`**: `"yaml"` or `"json"`

**`IncludeMigrationMetadata`**: Adds `x-epoch-migrations` extensions to schemas

### Two Generation Paths

**Path 1: Transform Existing Schema** (base spec has schema)
Expand All @@ -407,8 +398,7 @@ The generator uses different naming strategies depending on whether schemas are
- Example: `versionedapi.UserResponse` in all versions, with different fields

**Path 2: Generate From Scratch** (base spec missing schema)
- HEAD: uses bare name (`UserResponse`)
- Versioned: uses versioned name (`UserResponseV20240101`)
- Uses bare type name for all versions (e.g., `UserResponse`)
- Content generated from Go types + migrations applied

## Version Transformations
Expand Down
9 changes: 1 addition & 8 deletions epoch/openapi/config.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,13 +15,6 @@ type SchemaGeneratorConfig struct {
// OutputFormat specifies the output format ("yaml" or "json")
OutputFormat string

// IncludeMigrationMetadata adds x-epoch-migrations extensions to schemas (optional)
IncludeMigrationMetadata bool

// ComponentNamePrefix is added to all generated component names (e.g., "Astro")
// Results in component names like "AstroUser" instead of "User"
ComponentNamePrefix string

// SchemaNameMapper maps Go type names to OpenAPI schema names.
// Use this when your base spec uses different naming conventions.
// Common use case: Swag adds package prefixes to schema names.
Expand All @@ -31,7 +24,7 @@ type SchemaGeneratorConfig struct {
//
// Behavior:
// - If schema with mapped name exists in base spec → transforms it in place
// - If schema doesn't exist → generates from scratch using Go type name + version suffix
// - If schema doesn't exist → generates from scratch using Go type name
SchemaNameMapper func(typeName string) string
}

Expand Down
Loading