Inconsistent behaviour of `dependsOn` if set via initial resource config vs. via `resource.dependsOn`

[mihok]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Currently tokens are forced into strings, and dependsOn or addOverride resolves these down to templated strings, which are not allowed. Where a block of code such as this:

    const account = new ServiceAccount(scope, `${name}-account`, {
      accountId: name,
      description: "Generated by Terraform",
    });

    const key = new ServiceAccountKey(scope, `${name}-key`, {
      serviceAccountId: account.id,
      publicKeyType: "TYPE_RAW_PUBLIC_KEY",
    });

    key.dependsOn = [ account.id ];

Which results in the following error from terraform:

│ Error: Invalid expression
│ 
│   on cdk.tf.json line 102, in resource.google_service_account_key.logging-robot-key.depends_on:
│  102:           "${google_service_account.logging-robot-account.id}",
│ 
│ A single static variable reference is required: only attribute access and
│ indexing with constant keys. No calculations, function calls, template
│ expressions, etc are allowed here.

There needs to be a simple way for people to reference the object without templated strings.

Ideally, this might be as simple as having some kind of toUntemplatedString (ugly, not set on the name of the function/property)

So the above code would look something along the lines of:

    const account = new ServiceAccount(scope, `${name}-account`, {
      accountId: name,
      description: "Generated by Terraform",
    });

    const key = new ServiceAccountKey(scope, `${name}-key`, {
      serviceAccountId: account.id,
      publicKeyType: "TYPE_RAW_PUBLIC_KEY",
    });

    key.dependsOn = [ account.idRaw ];

Which result in a cdk.tf.json:

 
 "depends_on": [
   "google_service_account.logging-robot-account.id"
 ]

Happy to do some of the implementation if it helps!

[ansgarm]

Hi @mihok 👋

As you're using account.id in the key, Terraform should be able to automatically figure out the dependency between those two resources (you don't need to specify the dependency).
That said, if you would need to define the dependency, usually you would pass the whole resource into the dependsOn property: key.dependsOn = [account] (like done in HCL)

[mihok]

Thanks for looking at this @ansgarm, I reran the codebase with the instructions you have given me but Typescript suggests the value for dependsOn must be an array of strings, which is why I created this bug

[ansgarm]

Ah, got it. That's something we should check then 🤔
I came up with this because of this example which passes the resource construct:

terraform-cdk/examples/typescript/google/main.ts

Line 46 in 217b739

dependsOn: [network],

(we run examples in CI, so it should fail if TypeScript does not like that)

[ansgarm]

Okay, there seems to be an inconsistency between dependencies passed via the initial config (like in the example I posted) and setting the property later on.

This extra bit happens if dependsOn is defined in the config:

terraform-cdk/packages/cdktf/lib/terraform-resource.ts

Lines 95 to 99 in 217b739

	if (Array.isArray(config.dependsOn)) {
	this.dependsOn = config.dependsOn.map((dependency) =>
	dependable(dependency)
	);
	}

So, the proper way in your case would be to call:

import { dependable } from "cdktf";
// ...
key.dependsOn = [dependable(account)]

But I agree that this could use some more docs (at least inline docstrings on the dependsOn property; ideally some section in our docs).

[jsteinich]

Ideally setting after would also work with passing the entire object rather than needing to turn into a string. Can certainly improve documentation either way, but not requiring extra steps when late setting seems preferable.

[edwardch-ibotta]

is dependable something exposed in non-type script versions of the cdk?