Cannot use typescript template literals with terraform interpolation

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

cdktf & Language Versions

From my package.json

  "dependencies": {
    "@cdktf/provider-aws": "^9.0.3",
    "@cdktf/provider-kubernetes": "^2.0.3",
    "@eryldor/cidr": "^1.0.5",
    "cdktf": "^0.12.0",
    "cdktf-cli": "^0.12.0",
    "constructs": "^10.0.9",
    "ejs": "^3.1.6"
  },

Affected Resource(s)

None in particular. This seems like a problem with typescript + terraform interpolation + cdktf

Debug Output

Expected Behavior

I expect that I should be able to use typescript template literals

Actual Behavior

Typescript template literals are not being evaluated (or are incorrectly evaluated). I get the following errors (note that in the terminal output the second $ in each error is underlined):

[2022-07-29T10:22:38.612] [ERROR] default - ╷
│ Error: Invalid character
│
│   on cdk.tf.json line 191, in data.tls_certificate.certificate:
│  191:         "url": "${${aws_eks_cluster.eksCluster}.identity[0].oidc[0].issuer}"
│
│ This character is not used within the language.
goldsky-infra-dev  ╷
                   │ Error: Invalid character
                   │
                   │   on cdk.tf.json line 191, in data.tls_certificate.certificate (certificate):
                   │  191:         "url": "${${aws_eks_cluster.eksCluster (eksCluster)}.identity[0].oidc[0].issuer}"
                   │
                   │ This character is not used within the language.
                   ╵

⠙  Processing
[2022-07-29T10:22:38.628] [ERROR] default - ╷
│ Error: Invalid expression
│
│   on cdk.tf.json line 191, in data.tls_certificate.certificate:
│  191:         "url": "${${aws_eks_cluster.eksCluster}.identity[0].oidc[0].issuer}"
│
│ Expected the start of an expression, but found an invalid expression token.
goldsky-infra-dev  ╷
                   │ Error: Invalid expression
                   │
                   │   on cdk.tf.json line 191, in data.tls_certificate.certificate (certificate):
                   │  191:         "url": "${${aws_eks_cluster.eksCluster (eksCluster)}.identity[0].oidc[0].issuer}"
                   │
                   │ Expected the start of an expression, but found an invalid expression token.

Steps to Reproduce

This is happening during an upgrade from cdktf of 0.8.6 to 0.12.0.

Here’s the code which is causing the above issue:

    const dataTlsCertificateCertificate = new tls.DataTlsCertificate(
      this,
      "certificate",
      {
        url: `\${${eksCluster.fqn}.identity[0].oidc[0].issuer}`,
      }
    );

where eksCluster is a resource of type aws.eks.EksCluster.

It seems that I cannot use a javascript template literal when using terraform interpolation. Ninja edit: it seems that other uses of template literals are working well though, maybe something else is going on?

I’m using cdktf and the above issue happens when I run:

1. npx cdktf get
2. tsc
3. npx cdktf diff

Important Factoids

None that I can think of

References

• https://github.com/hashicorp/terraform-provider-template/issues/50

[DanielMSchmidt]

You can now express url: \${${eksCluster.fqn}.identity[0].oidc[0].issuer}, as url: eksCluster.identity.get(0).oidc.get(0).issuer

[ansgarm]

Hi @paymog 👋 This seems to be related to https://github.com/hashicorp/terraform-cdk/issues/1641. However, it seems to be a different result as it seems to render aws_eks_cluster.eksCluster (eksCluster) which probably originates from somewhere else (some .toString() method probably). The workaround that Daniel Schmidt posted in that other issue should work for you as well.

edit: What I’m trying to say is: We need to investigate this one as well as it is not exactly the same as #1641