-
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
Terraform Registry API Response Differs from Actual Implementation #27
Comments
This provides a fix for #12 and includes some refactoring around the resource parsing / emitting. The primary goal of the refactoring was, to split the parsing from the emitting to make it easier to understand. I'm still not quite happy with the result (in particular around the models, and that some logic is spread across multiple places). I think it needs another iteration, but for alpha it should do. Right now it's in the "it's working" state, and "jsii" will compile the "AWS" provider without an error. I haven't done a full sanity check of the generated resources, but for the most part it should be usable. In regards to the complex computed types, I'd see it as a first stab at the problem. It's not flexible and serves a very specific use case only. The goal: - Make complex computed types accessible - Provide type information for the computed properties of those types - Keep it within the constraints of jsii, namely no generics and no proxies (see #12) A few issues were created as a follow up - see #24 #25 #26 #27 #28 #29 #39
This provides a fix for #12 and includes some refactoring around the resource parsing / emitting. The primary goal of the refactoring was, to split the parsing from the emitting to make it easier to understand. I'm still not quite happy with the result (in particular around the models, and that some logic is spread across multiple places). I think it needs another iteration, but for alpha it should do. Right now it's in the "it's working" state, and "jsii" will compile the "AWS" provider without an error. I haven't done a full sanity check of the generated resources, but for the most part it should be usable. In regards to the complex computed types, I'd see it as a first stab at the problem. It's not flexible and serves a very specific use case only. The goal: - Make complex computed types accessible - Provide type information for the computed properties of those types - Keep it within the constraints of jsii, namely no generics and no proxies (see #12) A few issues were created as a follow up - see #24 #25 #26 #27 #28 #29 #39
Related issue reported with Terraform. hashicorp/terraform/issues/21417 |
Since we don't rely on the module registry anymore, this can be closed. |
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. |
For this VPC module, there's a discrepancy for the actual implementation of the inputs on Github and the API response of the Terraform registry.
Terraform Registry response:
Actual implementation
According to this blog post, the input should be optional when the
default
is set tonull
. Likely a bug in the Terraform Registry?This affects all inputs where the default is null (12 in this module). The effect is, that those variables are rendered as
required
attributes, and the Typescript compiler expects them to be set.I wonder if it's safe to assume that a
default
of""
(empty string) makes a variable always optional and we could ignore therequired
flag in those cases. Thoughts?The text was updated successfully, but these errors were encountered: