Thanks for the kind words.
Think it makes sense that to be able to have a “core” stack that handles things like the network stack. And other stacks can reference the core stack’s output.
It gets tricky when the core stack is in another TS_ENV and even trickier when it’s in another AWS account.
Unsure how to handle this yet. One of the reasons that current the output helper method only supports the same TS_ENV. This keeps the complexity down, in particular when it comes to resolving the dependency graph for the terraspace all command. Somewhat related thoughts here:
Talking about a env: common that possibly skips dependency graph calculation. So at least can access the terraform statefile and outputs programmatically. Orchestration and dependency graph would be skipped though.
Also, also thinking can define your own custom helper:
The custom helper could call the load the terraform statefile for outputs, call aws-sdk, or manually be updated with your core output values. The latter being the most non-ideal but is quickest and easiest. Think this is also non-ideal.
This is a tough one. Shared TS_ENV dependencies are a decent effort and may create too much complexity. Unsure will dig into this one more. Will consider ideas and PRs. Of course, no sweat either way 