This message was deleted.
# general
s
This message was deleted.
l
You'd have to write the code yourself. You can only import provider-level resources with the providers. It would be feasible to parse the
import
opt in your _ComponentResource_'s constructor, separate it into the multiple IDs you'd need to import the actual resources that the ComponentResource contains, and import them.
Usually, importing is a once-only thing, so it's usually just easier to import within the ComponentResource's code, targeting just one set of resources at a time. Then remove the import opts.
But if you're likely to be importing things frequently, then writing the code would would be the way to go.
s
got it, thanks!
are you aware of any example code? I’ve seen some docs on import as a resource option but not sure if there’s anything beyond that
l
No, I've never come across that. I suppose the need for repeated imports is not very common...
It does make me thing that I've got a bit of a bug in my code.. theoretically I could accidentally pass
import
into my component resources, then my could would blindly pass that on to all the nested resources, leading to many failed imports.. I guess I'll rely on code reviews to catch that...
s
I think you’re probably right, my code base is probably a lot more complex than most lol
my component resources are constructed with a bit of metaprogramming, lol
just got time to get back to this and it was pretty easy. i can put the resource id in the stack config when i am ready to import, and have my code check for its existence otherwise just create one
thanks a ton!
👍 1