This message was deleted.

There are many examples in the

examples

repo. Have you looked there? This is probably a good one to look at. It uses

ComponentResources

; not that you must also encapsulate yours as components: https://github.com/pulumi/examples/tree/master/aws-ts-wordpress-fargate-rds I also have a couple of examples of my own that may be quite large to read through but may give you a general idea: https://github.com/cloudy-sky-software/FoldingInTheCloud, https://github.com/cloudy-sky-software/botpress-pulumi

I'd like to verify what I think of as idiomatic TypeScript the preferred approach of the Pulumi community.

What are you looking to verify? 🙂

@clever-sunset-76585 thank you! i did peruse this repo, but mostly the GCP examples as that's the cloud I'm currently in. but i'm familiar with aws/fargate/rds so this is helpful. I notice the other files mostly export classes, and objects are constructed in the "main()" of

index.ts

... I'm trying to verify/refute an approach that uses top-level TS code in imported files, then simply references something exported so the transpiler won't throw away the require. This feels non-idiomatic to me, and largely side-effect driven. And, I don't see that pattern in these examples.

Ah yes. So I've used that approach with other code. The alternative is to be more explicit about creating the resources contained within other files by calling a function that arranges the creation of your resources. I understand the concern with the side-effect approach. It's certainly a convenience if you don't use component resources in the other files and don't want to write a function to create all the resources in the other files. It can also make exporting stack outputs a little cumbersome (and perhaps ugly) because you can only export in top-level code and not inside a func. Using component resources will force you to have to create that component resource or nothing encompassed inside it would be created so it's nice that way but of course that's not the only reason to use a component resource. So there's some sort of a tradeoff with both approaches.

Yeah, stack outputs have to be exported from index or returned from exported default async function, so exports in top-level code in other files don't result in stack outputs; one would need to "re-export" from index, correct? I guess I'm just trying to take an idiomatic TS approach and not foul the waters with style questions. Unfortunately, JS/TS is full of such things because it is so permissive (but golang is a bit too unweildly for IaC IMHO).

so exports in top-level code in other files don't result in stack outputs; one would need to "re-export" from index, correct?

I believe so, yes.

I guess I'm just trying to take an idiomatic TS approach and not foul the waters with style questions. Unfortunately, JS/TS is full of such things because it is so permissive (but golang is a bit too unweildly for IaC IMHO).

To be fair, I think it is idiomatic for infrastructure code to have resources created through the side-effect import due to its imperative nature. However, if you are dealing with a large/rapidly growing codebase, that's probably not ideal. Or if you are writing a library for IaC resources, you should use component resources anyway.