If anyone has ever tried to modularize their Pulum...
# typescript
f
If anyone has ever tried to modularize their Pulumi project and organize the code better than just a single big
index.ts
file, and also organize it so that infrastructure definition is separate from “runtime” application (e.g. Lambda code), you may have encountered issues with either compiling (module not found) or runtime (tslib not found) because you didn’t have all your runtime application code in the same part of the directory tree as the infrastructure code, and used
import
to either non-relative or
../
paths.
You might have stumbled on the
NODE_PATH=$PWD pulumi up
trick with tsconfig
paths
. https://github.com/pulumi/pulumi/issues/5455#issuecomment-877741098
I have a more precise solution too, summarized at https://github.com/pulumi/pulumi/issues/5455#issuecomment-877749759 with tsconfig
paths
in conjunction with package.json
workspaces
.
A blog is coming soon, which incorporates well-factored, modularized, TDD’d Pulumi infrastructure code and application code, as well as a simple pattern to successfully passing Output values to runtime application code. It also shows how to successfully run against LocalStack (for AWS projects).
Because, frankly, all the examples I’ve encountered so far are either far too basic to reflect reality or extremely unattractive in terms of maintainability or testability.
p
Looking forward to the blog post! Some lessons learned the hard way for us: • separate infra (e.g. clusters) stacks from stuff running on the clusters stacks. And use micro stacks, much easier to manage when stuff changes or fails. Using StackReferences • take care on destroying that you do it in order. Otherwise stuf on the cluster will never work again because the cluster has been replaced. Only way out is very difficult state json editing or destroying the stack, forcing you to reset all the variables (mostly secrets) (not a best practice but i have a secret folder on my desktop with a shell script to set all the configs) • don’t use functions you import for reusable parts, they do not get picked up. custom resources are the way to go. • don’t hardcode ‘names’ of e.g. namespaces or services. Ordering is better is you get it from the actual created variable and changes esier to implement • We have a mono repo all the stacks, and use GHA to see if there are code changes for a folder, and if so, use the pulumi GHA to run update in the changed folders. We do not loop but order the different ups manually since some of them depend on each other.
f
Awesome stuff, cheers!
d
@fierce-camera-61577 replying here from the other thread - I am gonna try now but I am confident it will work - I am not a typescript guru but my colleague did put my dependency (it was aws/codebuild) in the workspaces: {nohoist: [..]} I think if I change it to the other one aws/codepipine I need I'll be fine. Then I'll read the manual and figure out why it works 🤯
Nope this doesn't work and neither the NODE_PATH trick works - really weird. We might have changed something in the tsconfig ages ago but didn't change the infra for this bit in a while, so we didn't notice that the dependencies were not resolving
@proud-pizza-80589 I second all of that list, I had a blog post in mind for quite some time as well.
e
@fierce-camera-61577 Hi there. Saw this thread and I believe I’m having those issues, trying to modularize better the project and getting
module not found
on deployed lambda. I’m trying to get familiarized with Pulumi, so if that blog post has been published would be of help.
f
It’s being reviewed. I’ll publish this weekend!
🙌 1
e
Thanks for posting the link here!