Hi,
I know that in a “stack” I can use cdktf get to generate an importable representation of a “native” terraform module, and that’s awesome.
However, I’m wondering if the same is possible in a Construct library, I basically would like to do this:
cdktf stack → construct module → native terraform module
The construct module doesn’t have a “cdktf.json” file or anything, it’s just a plain ol typescript module. Is it still possible to run cdktf get etc?
Currently get reads the cdktf.json config file to get the list of providers and modules it should generate bindings for, but I think we’d be open to allowing those to be passed via flags, too.
Is there a reason against putting a cdktf.json config in the root directory of your construct module? Where would you define the dependency on the HCL module or woudl that be a one off task?
hi, thanks for responding. You’re right - after I posted this I realized that the only thing stopping me from doing cdktf get to generate the “imports” is a cdktf.json file (as you pointed out), so I just added one to my library repo and it all works perfectly (exctept that running cdktf deploy would likely fail.
I was thinking that having a type attribute in cdktf.json that informed the engine that “this is a construct, not a stack so only a subset of cdktf commands will work” would maybe be cleaner.
fyi, I linked this topic in a related documentation issue in Github. I agree that it might make sense to add something like a type attribute to handle the case of generating bindings for custom constructs (or to solve this in another way, e.g. without cdktf get directly but through Projen [which could also generate the files]).
