fix(aws-ssm): correctly emit Association.Name

[rix0rrr]

The rename used to happen in the cfnspec, which helped the model
generate correct names, but the code generator would lose the ability to
access the original name, and so it could not be emitted correctly.

Add a property renaming feature to the 'cfn2ts' code generator
(configured via a special entry in package.json).

Fixes #852.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.

[eladb]

Not sure I like this and it makes me wonder: maybe we should just get rid of the "name" => "xxxName" renames altogether in L1. The reason we are actually doing these renames was that the construct ID used to be a "name" prop, so if an L1 had a Name property, they would conflict.

However, now construct IDs are not a prop, and we technically don't need these renames at all.

[eladb]

Thanks for preserving the spirit

[rix0rrr]

The reason we are actually doing these renames was that the construct ID used to be a "name" prop, so if an L1 had a Name property, they would conflict.

True, that was the original reason. At the same time, I do like the transformation we're doing right now, if only to make the object model more consistent. The CloudFormation object model isn't always consistent in the names it uses, but I'd rather have our model be consistent.

For example (in no particular order, just random sampling from the CloudFormation model):

• AWS::Kinesis::Stream, AWS::CodeCommit::Repository: property Name.
• AWS::CodeDeploy::Application, property ApplicationName, AWS::DynamoDB::Table, property TableName.
• Not to mention AWS::SSM::Association which has both Name and AssociationName.

And at the same time, when we generate {GetAtt} and {Ref} getters, we do always add in the resource type into the name (for example { Fn::GetAtt: [Bucket, Arn] } -> bucket.bucketArn (as opposed to bucket.arn)). For consistency's sake we do use the resource type in there a lot, and I don't mind the explicit verbosity here.

I'm aware we could be providing this uniformity at the L2 level as well... but this is just such a convenient place to add it. I'm torn.

[eladb]

I think there is value in staying 1:1 with the CFN resource spec at L1. It makes it easier for people to navigate this layer, find help and in general have less magic. I vote for removing this sugar...

[RomainMuller]

Regarding the name prop... There are other conflict cases that we very much ignore at the moment, though... What will happen when some CFN resource gets a Path attribute is going to be not pretty.

[eladb]

@RomainMuller This is about the resource properties (props) not attributes, which are implemented as the properties of the construct (and we prefix the resource name to them all).

[RomainMuller]

Oh, duh. 🤦🏻‍♂️

[eladb]

@rix0rrr do you want me to pick this up?