https://pulumi.com logo
Join Slack
Powered by
anyone have general strategies for organizing pulu...
# general
m
anyone have general strategies for organizing pulumi projects? started to split up my infra into a few files and noticed pulumi is not detecting them in the way i expect. found an article for defining things as dynamic resources and grouping subcomponents into resources, but does pulumi not allow things like 
import * from webhooks
and it will instantiate whatever is in 
webhooks.ts
?
m
To clarify, you're asking about organizing code within a single pulumi project, not many pulumi projects in a single repository that need outputs from one another?
m
correct
in this example everything "belongs" to the same stack
i just don't want it all in the same file
like just as a trivial example, let's say i had a 
webhooks
stack that was concerned with integrations w/ different SaaS parts of our CICD pipeline. and let's say i had several REST endpoints configured w/ a gateway for each webhook provider; lets say there are three. so basically, i want 
index.ts
and three files; 
foo.ts, bar.ts, baz.ts
for each of the providers integrations
so far, from what i can tell, merely importing modules doesn't cause pulumi to register them as part of the current active stack
if i authored 
foo.ts
to look like 
index.ts
, as example, and i did the following in index.ts, nothing happens:
Copy code
import * from foo.ts
import * from bar.ts
import * from baz.ts
which is how i would normally organize a typescript project
i might be missing something basic here but typically when i try to do something 'standard' and it's not working, i'm missing something about the framework (or missing a dot on an i), so right now trying to decide where my error is, would appreciate some guidance if you had any
ok, interesting. i sort of discovered what i was doing wrong but it's still not what i might expect; 
import * as module from module
doesn't register, but 
import {resource} from module
does register
that makes sense to me but still concerning because i could see people easily making that error, would be good to know why we need to explicitly import tho
is this expected or should i log this as a bug?
l
Have you exported the resources from the other module? Pulumi doesn't do anything special re: imports, it's just the normal js/ts/node stuff. My general strategy is to define ComponentResources in other files, then instantiate instances of them in index.ts. This way, no "top level" code in other modules ever has to be considered. All code that is run "by default" or "as top level" is in index.ts.. but that's just a few calls to 
new MyResourceA(...()
, and all the important code is elsewhere.
m
they were exported, yeah
that's the pattern i've seen in a few other places (creating subcomponents and doing the top-level creation in index.ts)
l
What was the problem in your case? Did you have module-level code that wasn't being run?
I've never tried to got that working, and since all our devs come from an OO background, it's not something that would get past code reviews where I work. So we've never had an issue with modules that are supposed to do something automatically.. because none of our modules do anything automatically.
m
yeah, that was the problem. looking back it looks like i am able to do the default 
import * as X from "x";
as long as 
x
has a default export.
yeah, typically i'm pro that approach, but i was curious how it functioned and sometimes you want to know how you can organize stuff if there's no real good abstraction just to keep it fairly tidy
👍 1
b
Forgive me if im way off here. But isnt this a typescript issue rather than a pulumi one? We use Go and splitting it into modules etc works perfectly
l
Yes, completely. But we're keen to help anyone get value from Pulumi, no matter what the source of their problem...
b
I merely wanted to point out that asking in the typescript channel might give him more worthwhile answers, thats all...
💯 1
4 Views
Open in Slack
PreviousNext
Powered by