Summary

• Fix: Uses lazy evaluation for getDefaultApiType() so it's only called when a domain actually needs a default API type
• When all domains have explicit apiType, no API type detection is performed, avoiding the erroneous "Multiple API types
  detected" error
• The default API type is computed once and cached when needed

Problem

Previously, getDefaultApiType() was called unconditionally during initializeVariables(). When multiple API types
(HTTP, REST, WebSocket) were detected in the CloudFormation template, it threw an error:

Multiple API types detected in CloudFormation template: HTTP, WEBSOCKET.
Please explicitly specify the apiType for each domain configuration.

This happened even when all domain configurations already had explicit apiType specified, making it impossible to use
multi-domain configurations with different API types as documented.

Solution

Implement lazy evaluation: getDefaultApiType() is now only called when a domain configuration actually needs a default
(when apiType is not explicitly specified). The result is cached to avoid redundant computations.

Test plan

• Added 29 unit tests covering getDefaultApiType(), detectApiTypesFromTemplate(), and initializeVariables()
• Tests verify lazy evaluation behavior (getDefaultApiType not called when not needed)
• All existing tests pass
• npm run lint passes
• npm run prettier passes

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes & Improvements

  • Enhanced domain configuration with optimized API type detection and improved deferred computation handling.
  • Better fallback logic for domains without explicit API type specifications.

• Tests

  • Added comprehensive test coverage for domain configuration, API type detection, and multi-API type scenarios.

_{✏️ Tip: You can customize this high-level summary in your review settings.}