-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Description
Describe the bug
As a summary, CDK aws-apigateway module had a legacy file called apigatewayv2.ts which includes CDK L1 Constructs from API Gateway V2 resource like CfnDomainNameV2. We've already moved everything here to aws-apigatewayv2 module. However, we had to keep the legacy file for backward compatibility issue and every Constructs in the file were marked as deprecated 5 years ago.
Now API Gateway team has released a new AWS resource called DomainNameV2 in API Gateway. The default CDK generated name would be CfnDomainNameV2 in aws-apigateway module but this name collides with the legacy CfnDomainNameV2 Construct from apigatewayv2.ts file (supposedly for APIGatewayV2).
This is causing the L1 generation tool to fail because the new resource by API Gateway is also caused CfnDomainNameV2.
Regression Issue
- Select this option if this issue appears to be a regression.
Last Known Working CDK Version
No response
Expected Behavior
The new resource should be generated correctly
Current Behavior
It won't generate because of the name conflicts. We can either
Reproduction Steps
N/A
Possible Solution
- have a manual patch to the L1 generation script and we will name the new resource for API Gateway to be something more restricted as
CfnApiGatewayDomainNameV2. This is weird and confusing name. More importantly, if API Gateway team decides to introduce more resource under API Gateway but named it V2, we will need to add more manual patches. - delete the legacy apigatewayv2.ts file. We've now introduced aws-apigatewayv2 module and this is where users should use the constructs from. However, this would mean that this is a breaking change to users who're still on legacy code. Good news is that the existing
APIGatewayV2::DomainNameresource can't deploy with at least oneDomainNameConfigurationsproperty (even though this property says not required on CFN documentation, CFN deploy will throw an error). AndApiGateway::DomainNameV2resource doesn't have the same property so users won't be able to update to the latest CDK version and deploy unknowingly successfully. I also verified that if they update to use the same Construct fromaws-apigatewayv2module, it will generate the exact same output CFN template so it won't cause any resource replacement or downtime.
Additional Information/Context
No response
CDK CLI Version
N/A
Framework Version
No response
Node.js Version
N/A
OS
N/A
Language
TypeScript
Language Version
No response
Other information
No response