Skip to content
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

feat: Extend support for Terraform expressions #1131

Merged
merged 2 commits into from
Oct 11, 2021
Merged

Conversation

ansgarm
Copy link
Member

@ansgarm ansgarm commented Oct 11, 2021

…erator), property access (e.g. chaining x[1]["name"]) and operation expressions such as the unary ones (!, -) and binary ones (e.g. arithmetics, equality checks, boolean operators

also allows marking lazy values as inner values, which allows for proper token resolution

(these features are required for the aws adapter)
@ansgarm ansgarm marked this pull request as ready for review October 11, 2021 14:14
Copy link
Contributor

@skorfmann skorfmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good from a code point of view - I assume that's mostly for mapping purposes, so not really user facing - correct?

@ansgarm ansgarm merged commit e34a062 into main Oct 11, 2021
@ansgarm ansgarm deleted the extend-expression-support branch October 11, 2021 15:44
@ansgarm
Copy link
Member Author

ansgarm commented Oct 11, 2021

so not really user facing - correct?

Exactly, it is intended for mapping of intrinsic functions from CloudFormation in the AWS Adapter, like e.g.: https://github.com/hashicorp/cdktf-aws-cdk/blob/44fe1dfd6c058ec804379cf526940bad3eece638/src/aws-adapter.ts#L410-L419.

@@ -22,7 +22,7 @@ export class TerraformDataSource
// TerraformMetaArguments

public dependsOn?: string[];
public count?: number;
public count?: number | IResolvable;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the motivation for this? Numbers are generally encoded as tokens.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is required for CloudFormation Conditions support. Conditions can contain different intrinsic functions which I translate to Terraform functions which can return IResolvables instead of number encoded Tokens.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't you wrap it in Token.asNumber?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not try that 😅 Any reason to do it that way and switch back to only allowing number?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IResolvable is more difficult to use; especially in other languages. We haven't quite gotten there yet, but ideally we have consistent rules for when to use tokens encoded in native types and when to use IResolvable.

@jsteinich
Copy link
Collaborator

so not really user facing - correct?

Exactly, it is intended for mapping of intrinsic functions from CloudFormation in the AWS Adapter, like e.g.: https://github.com/hashicorp/cdktf-aws-cdk/blob/44fe1dfd6c058ec804379cf526940bad3eece638/src/aws-adapter.ts#L410-L419.

It's a bit unfortunate that at least the operators are done in a way that will make it difficult to make user facing in the future, but still probably for the best right now.

@ansgarm
Copy link
Member Author

ansgarm commented Oct 12, 2021

It's a bit unfortunate that at least the operators are done in a way that will make it difficult to make user facing in the future, but still probably for the best right now.

Yeah, we might want to put some thought into what to expose and why (i.e. which building patterns / best practices we might provoke in doing so).
However, for building advanced custom constructs using TypeScript, that are then made available via JSII (like e.g. the AWS CDK Adapter) they're already available to be consumed (at own risk).

@github-actions
Copy link
Contributor

github-actions bot commented Dec 7, 2022

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants