Legacy vs Modern Generator Testing for Vulnerabilities Package

Objective

Prove or disprove whether legacyGenerator is required for the vulnerabilities package through empirical testing with full comparison focusing on breaking changes and
type safety.

Phase 1: Setup & Baseline Documentation (5-10 min)

• Create testing branch: git checkout -b test-modern-generator-vulnerabilities
• Document current state:
  • Record current bundle size of vulnerabilities package
  • Capture current API surface (method signatures, interfaces)
  • Document current build times
  • Take screenshots/examples of generated code structure

Phase 2: Modern Generator Testing (10-15 min)

• Modify configuration:
  • Remove legacyGenerator: true from packages/vulnerabilities/project.json
  • Run nx run @redhat-cloud-services/vulnerabilities-client:generate
• Document generation process:
  • Capture any errors, warnings, or unusual output
  • Check if .openapi-generator/FILES is now created
  • Compare file structure (legacy vs modern)

Phase 3: Compilation & Type Safety Testing (10-15 min)

• TypeScript compilation:
  • Run nx run @redhat-cloud-services/vulnerabilities-client:build
  • Document any compilation errors
  • Compare generated TypeScript interfaces
• Type safety analysis:
  • Check method signatures for breaking changes
  • Verify complex parameter types are correctly generated
  • Test intellisense/autocomplete functionality

Phase 4: API Compatibility Analysis (15-20 min)

• Interface comparison:
  • Compare exported classes and methods
  • Check for missing or changed method signatures
  • Analyze parameter order and types
• Breaking change detection:
  • Test backwards compatibility with existing usage patterns
  • Document any API surface changes that would break existing code

Phase 5: Functional Testing (15-20 min)

• Runtime testing:
  • Create simple test script to call key API methods
  • Test both legacy and modern generated clients
  • Compare response handling and error cases
• Integration testing:
  • Test with actual API endpoints (if accessible)
  • Verify authentication and request formatting work correctly

Phase 6: Performance & Bundle Analysis (10-15 min)

• Bundle size comparison:
  • Measure generated code size (legacy vs modern)
  • Test final bundle impact in a sample application
  • Compare build times
• Performance testing:
  • Compare memory usage of generated clients
  • Test request/response performance

Phase 7: Analysis & Documentation (10 min)

• Create comprehensive comparison report:
  • Pros/cons of each approach
  • Specific breaking changes identified
  • Performance implications
  • Migration effort required
• Make evidence-based recommendation:
  • Whether legacy generator is truly required
  • If migration is viable, provide migration plan
  • If legacy is required, document specific technical reasons

Phase 8: Cleanup (5 min)

• Decision point:
  • If modern generator works: Keep changes and create PR
  • If legacy required: Restore original configuration
  • Update documentation with findings either way

Success Criteria

• Clear evidence whether modern generator can handle vulnerabilities API
• Complete understanding of any breaking changes
• Type safety verification
• Performance comparison data
• Clear recommendation with technical justification

Estimates

Total Time: 1.5-2 hours

Context

The vulnerabilities package currently uses legacyGenerator: true which prevents the creation of .openapi-generator/FILES required for the build-utils cleanup
script. This investigation will determine if the legacy generator is actually necessary or if it can be safely migrated to the modern generator.