Share config between multiple payload apps

metax_198194 days ago

10

• 

  zawoj4 days ago

  yeah, the @payloadcms/sdk client is generic over the Config type - new PayloadSDK<Config>(...) - so all you need is App B's generated Config type available in App A. Don't hand-write it; reuse what payload generate:types already produces.

  
  
  

  ---

  
  

  Monorepo (recommended): export App B's payload-types.ts and import it in App A.

  
  
  

  import type { Config } from 'app-b/payload-types'

  
  

  import { PayloadSDK } from '@payloadcms/sdk'

  
  
  

  const sdk = new PayloadSDK<Config>({ baseURL: '

  https://app-b.com/api

  ' })

  
  
  

  const { docs } = await sdk.find({ collection: 'posts' }) // fully typed to App B

• 

  metax_198194 days ago

  Thanks for the answer! Since I'm NOT in a monorepo (App A and App B are completely separate repositories), what is the best practice to distribute that generated

  payload-types.ts

  from App B to App A?

• 

  zawoj4 days ago

  Oh that will be harder.

  
  
  

  1. Publish a tiny types-only package

  
  

  2. Git submodule / git-dependency (no registry needed)

  
  

  Point App A's package.json at App B's repo directly:

  
  
  

  "dependencies": {

  
  

  "app-b-types": "github:yourorg/app-b#main"

  
  

  }

  
  

  App B keeps a committed payload-types.ts (it should anyway). Cheap, no publish pipeline - but you're pinned to a branch/commit, so it's coarser than semver.

• 

  metax_198194 days ago

  I'll think about which one fits our workflow better. Appreciate the help

• 

  zawoj4 days ago

  I can help on DM if needed!

• 

  metax_198194 days ago

  Thank you very much, I'll text you if I need a help!

• 

  anders22924 days ago

  You can do it in a much simpler way as well. Just a script in package.json which copies the file from one project to another.

  
  
  

  We have done that. Once you have new changes in CMS we generate types, and the types generation copies the generated types over to project B.

  
  
  

  We always keep our schema backwards compatible, so this way using the old generated types will still work when the app's are deployed at different times.

• 

  zawoj4 days ago

  This is one option too. The problem comes up when one person is on Windows and another is on a MacBook - but you could set up some kind of shared env to handle that. Yeah, this works as a solution as well.

  
  
  

  But still cleanest way will be nx monorepo or trubo.

• 

  metax_198194 days ago

  Thanks guys! Looking at all these monorepos, submodules, and CI/CD pipelines... I think I can easily survive without strict types for now. I only have 2 collections anyway, so typing them manually or using

  any

  sounds like the best practice for my mental health right now 😂

• 

  anders22924 days ago

  Yeah, it can be a lot of infrastructure to set up for little gain. So you have to weigh it.

  
  
  

  We use copy, monorepos and some where we create package. Each has their own pros and cons. Kacper mentioned some cons with one method.