Aspects and Design decisions

Terraform CDK for Terraform
1

Hi all,
currently I am looking into Aspects to add tags to certain resources.

export class TagsAddingAspect implements IAspect {
  constructor(private tagsToAdd: Record<string, string>) {}

  // This method is called on every Construct within the specified scope (resources, data sources, etc.).
  visit(node: IConstruct): void {
    node.node.findAll().map((e) => {
      if (e instanceof TerraformResource) {
        if (e.hasOwnProperty('_tags')) {
          // eslint-disable-next-line @typescript-eslint/ban-ts-comment
          //@ts-ignore
          e['_tags'] = { ...e['_tags'], ...this.tagsToAdd }
          // eslint-disable-next-line @typescript-eslint/ban-ts-comment
          //@ts-ignore
          console.log(e['_tags'])
        }
      }
    })
  }
}

beside that i find it a bit strange why all private attributes are implemented with _. That leads to a lot of trouble, e.g. destructuring. You end up with strange things likes const { attr: _attr = '' } = { ...resource } to satisfy the compiler and the above code is as well not really nice.

Maybe I am just doing something wrong, so if anybody has a better solution I would be really glad to hear it.

regards
Mathias

2

There is a tagging example in the documentation which doesn’t try to access the private field: Aspects | Terraform by HashiCorp.
I do however wonder if that example actually works.

The _ naming is actually a common convention for private fields (I’m personally not a big fan of it). Effectively a private field is used to hold any user specified values, while publicly returning a reference.
Using tagsInput would probably be better for accessing existing values. Using the public setter to update would be good as well.

3

Thanks for your reply, I know the example, but it is no longer valid, well I just life with it :wink:

4

Would you mind creating an issue about this. At the very least the example should be fixed, but it also seems like a use case that should be improved.