https://pulumi.com logo
Join Slack
Powered by
I’m a typescript user and new to pulumi. I see th...
# general
i
I’m a typescript user and new to pulumi. I see that the sample 
index.ts
has certain things 
clusterName, kubeconfig
exported, but there is no explanation why. I’m assuming pulumi needs these named exports, but feeling a bit in the dark. I’m expecting the ts to be strongly typed; I was expecting to export something conforming to an 
interface
for example.
Is there a place I can read about how the cli interfaces with the module or just look at code?
g
Exports are generally used for publishing values that you wish to access outside your application. They'll be printed out separately once your app completes.
i
publishing them to…who?
To publish values that you wish to access outside your application, create a stack output via module exports.
I’m confused … in that I use pulumi to deploy my app which e.g. has a defined ingress. Who would I export these values to? What would consume them?
Or is this just an export, like any other ts module and you have to write ts code to consume them?
The reason I ask is because tutorials have code like:
Copy code
// Export the Deployment name
export const deploymentName = deployment.metadata.apply(m => m.name);
and the comment isn’t helpful. I can see it is an export, but will pulumi fail without it? or is it simply to expose internals for reuse with my potential other code?
When I remove the exports, it seems I have 
3 unchanged
resources, so it appears these exports are typical ts module exports for reuse. Unless I’m wrong, I’d suggest a change to the doc code - exports are only needed if they are reused. In this case it looks like they are not (which led to my confusion)
Ohhh, I think I get it now. They will be displayed - so it’s an informational thing?
g
Yes, sorry for the confusion.
They're either A) informational for the you the end user or B) informational for other Pulumi applications.
You're able to reference other stacks via 
StackReference
so you can break apart your infrastructure into different "deployable units" and manage them independently.
A good example is you might have a VPC stack that publishes it's VPC and Subnet IDs and then another application stack that consumes those to deploy VMs or other resources into that VPC and Subnets.
i
Thanks, I did see stack references and that makes sense.
Open in Slack
PreviousNext
Powered by