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

Module Generation Should Generate Output Getters #28

Closed
skorfmann opened this issue Apr 26, 2020 · 2 comments · Fixed by #41
Closed

Module Generation Should Generate Output Getters #28

skorfmann opened this issue Apr 26, 2020 · 2 comments · Fixed by #41
Milestone

Comments

@skorfmann
Copy link
Contributor

At the moment, the module generator generates accessors and interfaces for inputs. We should extend it to provide getters for outputs as well.

@skorfmann skorfmann added this to the v0.0.1 alpha milestone Apr 26, 2020
@skorfmann
Copy link
Contributor Author

FYI: The fetch latest module version logic isn't working properly on master, since it's sorting alphabetically rather than numerically. This is fixed in #31 with 88f80be

skorfmann added a commit that referenced this issue Apr 30, 2020
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
anubhavmishra pushed a commit that referenced this issue May 5, 2020
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
@github-actions
Copy link
Contributor

github-actions bot commented Dec 9, 2022

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 9, 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 a pull request may close this issue.

2 participants