feat(core): Add resource type and properties of all CfnResource constructs to tree.json

[nija-at]

Also, switch the children node from an array to an object with each child object keyed on its id.

TODO:

• Support for tokens

---

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

[mergify]

Thanks so much for taking the time to contribute to the AWS CDK ❤️

We will shortly assign someone to review this pull request and help get it
merged. In the meantime, please take a minute to make sure you follow this
checklist:

• PR title type(scope): text
  • type: fix, feat, refactor go into CHANGELOG, chore is hidden
  • scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
  • text: use all lower-case, do not end with a period, do not include issue refs
• PR Description
  • Rationale: describe rationale of change and approach taken
  • Issues: indicate issues fixed via: fixes #xxx or closes #xxx
  • Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
• Testing
  • Unit test added. Prefer to add a new test rather than modify existing tests
  • CLI or init templates change? Re-run/add CLI integration tests
• Documentation
  • README: update module README to describe new features
  • API docs: public APIs must be documented. Copy from official AWS docs when possible
  • Design: for significant features, follow design process

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[eladb]

This seems upside down...

I don't think CfnResources should be special nor that the tree should encode the concept of type and properties. I believe the design we discussed was that each tree node has a set of key-value attributes and constructs can "contribute" to this attribute bag by implementing some interface. Then CfnResource implements the interface and contributes the attributes aws.cloudformation.type and aws.cloudformation.properties (which will be key/value pairs).

Something like:

interface ITreeAttributes {
  treeAttributes: { [key: string]: any };
}

And then:

class CfnResource implements ITreeAttributes {
  public get treeAttributes() {
    return {
      'aws:cloudformation:type': this.resourceType,
      'aws:cloudformation:properties': this.cfnProperties
    }
  }
}

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[shivlaks]

This seems upside down...

I don't think CfnResources should be special nor that the tree should encode the concept of type and properties. I believe the design we discussed was that each tree node has a set of key-value attributes and constructs can "contribute" to this attribute bag by implementing some interface. Then CfnResource implements the interface and contributes the attributes aws.cloudformation.type and aws.cloudformation.properties (which will be key/value pairs).

Something like:

interface ITreeAttributes {
  treeAttributes: { [key: string]: any };
}

And then:

class CfnResource implements ITreeAttributes {
  public get treeAttributes() {
    return {
      'aws:cloudformation:type': this.resourceType,
      'aws:cloudformation:properties': this.cfnProperties
    }
  }
}

This is my miss for not closing the RFC sooner. Yes we did decide that we would have an attribute bag and constructs will provide information into it. L1's would report back all the properties in toCloudFormation. L2s would optionally contribute properties that are configurable, properties of interest, etc.

Type was the thing we hadn't closed discussion on. Initially, I felt it's nice to have as a top-level attribute of a Node, but I agree that since it's not applicable to every construct, that it's better off living in the attribute bag.

I'll update the RFC to make the change to nest type into the attribute bag of a tree node, rather than a top-level attribute.