fix(lib): better error for uninitialized provider #896
Conversation
DanielMSchmidt
force-pushed
the
better-handling-of-missing-provider-construct
branch
12 times, most recently
from
5f2d8f6
to
289c43d
Compare
DanielMSchmidt
force-pushed
the
better-handling-of-missing-provider-construct
branch
2 times, most recently
from
4f1358e
to
269de97
Compare
DanielMSchmidt
force-pushed
the
better-handling-of-missing-provider-construct
branch
from
269de97
to
25cbcc7
Compare
DanielMSchmidt
force-pushed
the
better-handling-of-missing-provider-construct
branch
2 times, most recently
from
7cf9a9e
to
fbcc044
Compare
we now depend on a feature added in 3.1.0
DanielMSchmidt
force-pushed
the
better-handling-of-missing-provider-construct
branch
from
fbcc044
to
29b11bb
Compare
There was a problem hiding this comment.
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)
DanielMSchmidt
deleted the
better-handling-of-missing-provider-construct
branch
|
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