feat(lib): update attributes['//'] instead of assigning to it

[rirze]

Should allow end users to also write to the "//" attribute in Terraform resources. Currently, cdktf overwrites this attribute with the metadata values.

[DanielMSchmidt]

That's an interesting use-case, what do you plan to use the // field for?

[rirze]

Personally, I'm using this to test out a Pulumi-style import behavior. Essentially, I would attach an importId parameter into the // attribute, then run a script that generates terraform import ... statements based on the type of resource and the importId given.

Without this, I don't see any side-effect free way to 'tag' Terraform resources so I can identify which resources to import just by looking at the generated cdktf.json alone.

Hopefully that gives you some context-- I have no intention to alter the existing metadata that cdktf attaches. If you're collecting that data, maybe I can restrict the library to only set the //.metadata attribute?

[DanielMSchmidt]

Ah interesting, please let us know how it went 👍

[DanielMSchmidt]

Could you run yarn format to make CI pass?

[rirze]

Sure, I'll make sure to run yarn format.

I was thinking, as a way to expand this idea; should I implement a addComment function to TerraformResource (and probably TerraformStack too...)? Currently I'm using overrides to add this "comment" to a resource, but it results in this top level list of "overrides" in the cdktf.json. I'm trying to figure out if a more native solution would be ok.

Let me know your thoughts.

[jsteinich]

I was thinking, as a way to expand this idea; should I implement a addComment function to TerraformResource (and probably TerraformStack too...)

I don't think addComment makes sense as the json output isn't meant to be read by a human. Perhaps addMetadata would be a better name.

Personally, I'm using this to test out a Pulumi-style import behavior. Essentially, I would attach an importId parameter into the // attribute, then run a script that generates terraform import ... statements based on the type of resource and the importId given.

This sounds like something could be built into cdktf. Probably not in the context of this PR, but possibly as part of #1134.

[ansgarm]

Seconding in on addComment:

We already have support for Annotations (used for example in the last code block in the Aspects docs). Those Annotations serve the purpose of adding a comment to a construct. They are printed when running synth and (in the case of error) can even fail the synth process.

While addMetadata would certainly be a better name, I am a bit hesitant to just add that functionality without having done a bit more research on what kinds of workflows this is supposed to enable.

As Jon said, the import behavior would certainly be something that should be included as a first class citizen in the CDKTF with a clear and straight forward API.

---

Currently I'm using overrides to add this "comment" to a resource, but it results in this top level list of "overrides" in the cdktf.json.

I think we could exclude all overrides nested in // to get rid of this to help with that.

To make the way of interacting with the overrides for // more beautiful to work with, you could build yourself a helper with an API similar to Annotations.of() or Aspects.of(). Something like this (untested):

class Imports {
  protected constructor(private target: TerraformResource) {}

  public static of(target: TerraformResource) {
    return new Imports(target);
  }

  public addSomeConfig(config: any): this {
    this.target.addOverride("//.__imports_config", config);
    return this;
  }
}

Imports.of(myS3Bucket).addSomeConfig({ todoo: 'put something here' })

[rirze]

All those who were interested in my approach on how I was automating importing resources, I wrote a detailed comment @ #1134 (comment).

I can provide more details as needed and I'd be comfortable moving the discussion regarding that to another issue/PR if necessary.

[hashicorp-cla]

All committers have signed the CLA.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.