Import and use App constructs from CDK libraries
#1485
Assignees
Labels
Comments
Chriscbr
added
✨ enhancement
mergify bot
pushed a commit
that referenced
this issue
Feb 13, 2023
Closes #477 This PR adds the underpinnings of support for `bring`-ing JSII libraries. The following list of limitations is not comprehensive: 1. Our compiler doesn't support static class/resource members yet, so types with static members may not be imported properly. (#107) 2. Our compiler doesn't support interfaces, so many Terraform libraries currently fail to import. (#1024) 3. Our compiler doesn't support variadic parameters, so methods with such parameters are not available. (#397) 4. Our compiler doesn't support importing enums yet. (#1484) 5. Constructs named `App` cannot be imported (these constructs typically do not have a `scope` and `id` so we would need to model them differently in the compiler in order to make them usable) (#1485) The core of the changes in this PR are in the `jsii_importer`. The JSII importer now imports all types into nested namespaces inside a new symbol environment named `libraries`, based on the fully-qualified names (FQN) of types. For example, when the SDK is imported through `bring cloud;`, the jsii importer creates a symbol named `@winglang/sdk` in the global namespace that points to a `Namespace` struct. This namespace has its own symbol environment (a lookup table), and a symbol named `cloud` is added to it pointing to another `Namespace`. That namespace's symbol environment is then given symbols pointing to each type in the `cloud` namespace. The motivation for this model is that no type will ever get imported multiple times (it's not possible for `cloud.Bucket` to get imported twice, even if you were theoretically able to do `bring cloud; bring sdk;`). I'm not sure if this will hold water forever (will Wing apps allow multiple copies of a library in its dependency closure...?) but for now it seemed like a helpful assumption. Types are automatically inserted into the correct namespace -- so whenever types are needed from other namespaces (for example, `cloud.BucketBase` needs to reference it's base type, `core.Resource`), a new namespace is created ad-hoc in the correct place (in this example, as a sub-namespace of `@winglang/sdk`). Finally, when all types are imported into appropriate namespaces, the JSII importer will create a symbol in the global symbol environment named `cloud` which points to the `cloud` namespace within `@winglang/sdk` inside `libraries` . This is the basis of the `bring "my-lib" as my_whatever` import name assignment. Other changes: - Namespaces are now allocated in a vector so that we can construct multiple pointers to a single namespace. - Clean up comments (the convention in Rust is that docstrings are commented with three slashes -- once we do this, the comments appears on mouse hover in IDEs like VS Code) - StmtKind::Use is renamed StmtKind::Bring - Several parts of the compiler have been updated to use &Path instead of &str wherever a path is being referenced - Create a "FQN" type for organizing FQN-related operations. Future work: - #1414 - #1487 - #1488 - #1515 - #1516 - #1517 *By submitting this pull request, I confirm that my contribution is made under the terms of the [Monada Contribution License](https://docs.winglang.io/terms-and-policies/contribution-license.html)*.
|
Hi, This issue hasn't seen activity in 60 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. |
|
Hi, This issue hasn't seen activity in 60 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. |
5 tasks
5 tasks
|
Congrats! 🚀 This was released in Wing 0.22.23. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Community Note
Feature Spec
An
Appis typically a construct at the root of a construct tree. Unlike other constructs, mostAppclasses do not expect ascopeandidas their first arguments so they would need to be code-generated differently in the compiler.Use Cases
As a user, I would like to use Wing for authoring CDK libraries and apps with other CDK frameworks like cdk8s
Implementation Notes
Today these classes cannot be imported because our compiler hardcodes an assumption that every construct has an implicit scope and id when emitting JavaScript code.
Component
Language Design, Compiler
The text was updated successfully, but these errors were encountered: