-
Notifications
You must be signed in to change notification settings - Fork 457
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
fix(lib): better error for uninitialized provider #896
fix(lib): better error for uninitialized provider #896
Conversation
5f2d8f6
to
289c43d
Compare
4f1358e
to
269de97
Compare
269de97
to
25cbcc7
Compare
7cf9a9e
to
fbcc044
Compare
we now depend on a feature added in 3.1.0
fbcc044
to
29b11bb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another conceptual question related to this:
We currently don't advise how users should re-use and pass providers between constructs and/or stacks and this is probably an edge case, but in the Terraform world it is common to define a provider and let modules inherit that one (afaik). If a user wants to use the CDKTF to build such a "provider-config-agnostic" module now, would this change force them to define a provider although they wouldn't want to? (Not that this is a bad thing or a blocker – I just wanted to bring this up)
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. |
Fixes #822
Fixes #473