-
Notifications
You must be signed in to change notification settings - Fork 456
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aws_acm_certificate.*.domain_validation_options throws Invalid index #424
Comments
This may require a bit of discussion. Currently lists and sets are treated the same in cdktf; however, they aren't the same in Terraform. The workaround proposed here would allow accessing by index; however, I believe converting a set to a list doesn't guarantee ordering which could result in differences between plans. Actually generating a set type is possible, but a lack of generic support would make it a fairly large task. |
@jsteinich do you have something in mind how to tackle this? |
Ideally jsii would support |
#992 tracks this issue, Closing this one so we only have one issue that tracks the effort |
for providers sets are exposed as lists (as they previously were) but when setting or retrieving them, the returned token will be wrapped in toset or tolist respectively. As sets are not yet supported by JSII, we will convert them to lists so that accessing individual elements works as inferred from the array type which is currently used to model sets in TypeScript. Addresses for example #424
for providers sets are exposed as lists (as they previously were) but when setting or retrieving them, the returned token will be wrapped in toset or tolist respectively. As sets are not yet supported by JSII, we will convert them to lists so that accessing individual elements works as inferred from the array type which is currently used to model sets in TypeScript. Addresses for example #424
for providers sets are exposed as lists (as they previously were) but when setting or retrieving them, the returned token will be wrapped in toset or tolist respectively. As sets are not yet supported by JSII, we will convert them to lists so that accessing individual elements works as inferred from the array type which is currently used to model sets in TypeScript. Addresses for example #424
for providers sets are exposed as lists (as they previously were) but when setting or retrieving them, the returned token will be wrapped in toset or tolist respectively. As sets are not yet supported by JSII, we will convert them to lists so that accessing individual elements works as inferred from the array type which is currently used to model sets in TypeScript. Addresses for example #424
for providers sets are exposed as lists (as they previously were) but when setting or retrieving them, the returned token will be wrapped in toset or tolist respectively. As sets are not yet supported by JSII, we will convert them to lists so that accessing individual elements works as inferred from the array type which is currently used to model sets in TypeScript. Addresses for example #424
for providers sets are exposed as lists (as they previously were) but when setting or retrieving them, the returned token will be wrapped in toset or tolist respectively. As sets are not yet supported by JSII, we will convert them to lists so that accessing individual elements works as inferred from the array type which is currently used to model sets in TypeScript. Addresses for example #424
for providers sets are exposed as lists (as they previously were) but when setting or retrieving them, the returned token will be wrapped in toset or tolist respectively. As sets are not yet supported by JSII, we will convert them to lists so that accessing individual elements works as inferred from the array type which is currently used to model sets in TypeScript. Addresses for example #424
for providers sets are exposed as lists (as they previously were) but when setting or retrieving them, the returned token will be wrapped in toset or tolist respectively. As sets are not yet supported by JSII, we will convert them to lists so that accessing individual elements works as inferred from the array type which is currently used to model sets in TypeScript. Addresses for example #424
for providers sets are exposed as lists (as they previously were) but when setting or retrieving them, the returned token will be wrapped in toset or tolist respectively. As sets are not yet supported by JSII, we will convert them to lists so that accessing individual elements works as inferred from the array type which is currently used to model sets in TypeScript. Addresses for example #424 fix(provider-generator): don't supply third arg for String|Number|Boolean Map types. remove return type to let TS narrow it down automatically to give a narrower type
for providers sets are exposed as lists (as they previously were) but when setting or retrieving them, the returned token will be wrapped in toset or tolist respectively. As sets are not yet supported by JSII, we will convert them to lists so that accessing individual elements works as inferred from the array type which is currently used to model sets in TypeScript. Addresses for example #424 fix(provider-generator): don't supply third arg for String|Number|Boolean Map types. remove return type to let TS narrow it down automatically to give a narrower type
I'm going to lock this issue 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 similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Community Note
cdktf & Language Versions
Affected Resource(s)
Debug Output
Expected Behavior
Actual Behavior
"${tolist(aws_acm_certificate.cdktf_notificationappcertificate_680C64C0.domain_validation_options).0.resource_record_name}"
when added "tolist" into cdk.tf.json it works completed
Steps to Reproduce
Important Factoids
References
ref: hashicorp/terraform#26043
bug fix Implement
The text was updated successfully, but these errors were encountered: