Hi - we're using Azure + TypeScript in a monorepo managed by pnpm and turborepo and having some trou...
b
Hi - we're using Azure + TypeScript in a monorepo managed by pnpm and turborepo and having some trouble determing this best setup for our pulumi files. https://www.pulumi.com/blog/nx-monorepo/ this blog was helpful, but it doesn't do a great job of showing how the repo would scale. If I wanted to add a second website, would it look something like this:
Copy code
-pulumi-components
-website1
-website2
-infra1
-infra2
or more like this:
Copy code
-pulumi-components
-apps
   -website1
   -website2
-infra
   -website1
   -website2
or maybe something like this?
Copy code
-pulumi-components
-apps
   -website1
       -infra
       -app
   -website2
       -infra
       -app
I could probably make all of them work, but I'm wondering if anyone has more perscriptive advice or ideas. Thanks!
b
I think when they say mono here, they mean the infra code and source code
l
As you say, any of them could work. Personally I'd choose the 3rd option, as it is then obvious which bits are specific to a particular app. If you get rid of website2, then you just delete that directory. If you want to deploy a new version of website1 (that requires some infra changes), then you just run some script in website1, and you don't need to remember to change to some other directory and run some other script afterwards. I would have a place to put shared code / classes / components too.
I like the convention I see in a lot of open source JS/TS projects, with non-apps (shared code) in /lib and app (including Pulumi projects) in /src. So you might have /src/website1/infra and /lib/pulumi/myvpc.
But ymmv
b
But if are doing it like how you are suggesting, I would agree with tenwit and putting everything under each service
b
yeah the way we're currently setup we have: -packages (for shared code) -apps (for deployables) which makes it easy to configure in turborepo because we can define our pnpm workspaces as so:
Copy code
packages:
  - "apps/*"
  - "packages/*"
So in this case would the app code and pulumi infra code share a package.json?
If not, I think we would have to define every single package individually which might be annoying but I guess isnt a deal breaker:
Copy code
packages:
  - "apps/webapp1/app/*"
  - "apps/webapp1/infra/*"
  - "apps/webapp2/app/*"
  - "apps/webapp2/infra/*"
b
thats why i personally would keep them separate since they have different packages. But its really up to you and how you want to do it. There is no right answer
b
or maybe the move is to make the pulumi infra folders not be monorepo packages and instead require each
/apps/*/app
to have an npm script that basically just aliases the pulumi infra commands
actually that would probably have to be a bash script because there is no way to make sure the pulumi package has dependencies installed and is built
that all feels wrong and bad. Maybe we just have to list out every package one at a time. Not the end of the world but does feel like a regression on our current setup where you can add another package or app without having to update pnpm workspace config
either way, sounds like I just need to figure it out and there isn't much perscriptive guidance out there. Thanks all!
b
if you figure something out, make sure to create a blog post about it. This is an area where I don't see enough posts about. How to structure and design your repo.
l
You can nest directories with package.jsons. Nothing wrong with having apps/website1 have a package.json which knows about the two packages in apps/website1/app and apps/website/infra. That's approximately what I do.
No need for bash anywhere. I use bun everywhere, I've used yarn everywhere and npm everywhere on previous projects.
Just make sure you are setting
private: true
for all your Pulumi projects. You'll never want those packaged / deployed anywhere.
b
ahh maybe its a turborepo problem then:
l
Ah. Looks like it. I've never used turborepo. (In fact, I've never heard of turborepo 😊 )