Expose props as read/write properties in CFN resources and remove propertyOverrides

[rix0rrr]

Perfectly reasonable application of aspects came up on Gitter:

Hello, I'm trying to write a custom IAspect which sets the RoleName of any IAM Role in a stack to
include a particular prefix (for resource matching in IAM permissions). Unfortunately, this overrides
any RoleName that is manually set in the stack itself.
Is there a way for an IAspect to check whether an IAM Role already has RoleName set?

To enable this we would need to allow read/write access to the configured properties of a CfnResource, in a typed fashion (so it needs to be done in cfn2ts).

We need to think about types and JSII though.

A RoleProps struct will have readonly properties for evertyhing, so cannot be mutated. So the syntax will have to be something like:

cfnrole.properties = {
   ...cfnrole.properties, 
   roleName: 'MyPrefix-' + cfnrole.properties.roleName
};

Not great...

Same story across JSII, except in Javaland it will be even more annoying to copy the existing properties into a new builder object. We need to generate a "copy constructor" as well then.

[rix0rrr]

We could say "overrides!" but in that case it looks like:

cfnrole.propertyOverrides.roleName = 'MyPrefix-' + cfnrole.properties.roleName

Which I agree is slightly better, but super non-obvious.

Also if propertyOverrides is typed as the same struct type the readonly is going to disallow this as well.

[Doug-AWS]

Is this yet another version of an escape hatch?

[eladb]

The proposal is to expose all top-level L1 props as simple read/write properties of the construct (note that deep structs will still be readonly, but that should be fine).

So for example:

class interface CfnBucketProps {
  // ...
  readonly corsConfiguration?: CorsConfigurationProperty;
  readonly bucketEncryption?: BucketEncryptionProperty;
  // ...
}

export class CfnBucket {
  // ...
  public corsConfiguration?: CorsConfigurationProperty;
  public bucketEncryption?: BucketEncryptionProperty;

  // ...
}

Also, remove propertyOverrides (it's no longer useful).

Then, in _toCloudFormation rendering should happen from the properties of course to allow overrides to take effect.

@moofish32 might pick this up.

Discussed with @rix0rrr and @RomainMuller

[eladb]

A little note - we hope 🤞 that this does not conflict with attribute property names because they begin with the type name (e.g. bucketArn)

[RomainMuller]

We could also code generate an IInterface for that mutable property. This should also feature an arbitrary accessor ([key: string]: any) so people could leverage properties that did t make it to the spec yet.

It'd maintain the namespace-like encapsulation that prevents name collisions from being a problem, and retain the strong typed overrides. It may need a JSII feature to support objects with an index signature.

[eladb]

I am not sure it's worth the effort, and the developer experience is less attractive:

bucket.corsConfiguration = { boom! };

versus:

bucket.props.corsConfiguration = { bam! };

I doubt we'll ever have conflicts and if we do, and we can should implement this logic to mangle the property name if there's an attribute with exactly the same name (e.g. add something like a "Config" postfix). At any rate, if this will happen, it will be a very fringy edge case.

[moofish32]

Just to verify I'm thinking in line with the team a starting point might be:

1. Modify code generation to create a class property for each CloudFormation Property currently in the immutable Cfn<resource>Props interface
2. Keep the constructor with the immutable Cfn<resource>Props (no change here)
3. After class initialization assign & read all properties from the class members do not persist the properties class member (renderProperties method should now assemble the properties back into an object?)
4. Delete all references to the propertyOverrides solution

[rix0rrr]

Yep, that's about it what we were thinking as well.

[moofish32]

I'm digging in here, the code needs a little unwinding. Hopefully I'll have something in a couple of days.