[Solved] Add separate repo support (Markdown content in one, Next.js in another)

[perkinsjr]

I have been investigating a way to create a flow that:

1. Contains all markdown content in a repository
2. Contains the Next.js / Tina code.

This flow will allow developers to not have to worry about sifting through commits / PRs that are content-related only. This is also something that people have asked for in the past.

It seems that we would need to tell the CLI where to look for the path to tina and find a way to support this locally.

Thoughts?

[llibdude]

I would love this feature. I would also love the ability to have multiple markdown repos attached to one nextjs project. Pretty much for the same reason, remove noise between document types that are run on the same app. I would guess this might be a more technical challenge

[coreyaus]

Yeah, we'd absolutely love this too!

At some point I was hoping to explore this in a little more detail - not sure how well I would have fared with this but the initial ideas I was thinking of experimenting with were:

• attempting to use git submodules for the content repositories (aiming to have multiple sites built from the same Tina/Next.js code as you both mention)
  • I'm pretty sure Netlify/Vercel provide ways to access private submodule content in the build process
• creating a private npm package and attempting to effectively turn the main Next.js code into a theme that could be installed as a dependency on multiple content repositories. My sense is that this would be a hassle though with versioning, etc.

Anyway, excited to see this being discussed and figured I'd share those very rudimentary thoughts in case they're of any use, but a recommended path baked into the tina config would be the dream!

[llibdude]

I have take a few minutes to try and think this out myself. I think in either scenario you are left needing multiple Tina projects OR not being able to keep tina sync'd with all the submodules (assuming tina is at the root).

I didnt try to break out any code but if you ever figure something out please share!

[jeffsee55]

It seems that we would need to tell the CLI where to look for the path to tina and find a way to support this locally.

I think there are 2 approaches to solving this:

1. Install the @tinacms/cli in the "content repo". At first glance, is the most straightforward, but it comes at a cost. We're introducing the requirement that your frontend TinaCMS config has to take in schema as a prop. This allows you to provide runtime functions directly in your schema for things like custom UI components, validators, and default values. And obviously the ergonomics here don't work very well when the .tina/schema.ts is in another repo. You'd need to import that schema definition back into your Tina-enabled project somehow.

2. Provide a "path/to/content/root" property as a CLI config (or command). In this approach, the content repo would have your content folders + .tina folder with just the __generated__ items in it. Note that this config will be specific to you local setup, so you may have your content repo adjacent to your Tina-enabled website repo, but it should probably be configurable. We'd still need you .tina folder in this repo, so there would be some duplication (I think).

[coreyaus]

Hey mate,

I was just returning to this now that I have more context around option 1 (following the release of the update you mentioned where TinaCMS config takes schema as a prop). I have a question about each of those possible approaches you outline:

1. Would there be an option to install @tinacms/cli in the "content repo" but keep the schema.ts in the main repository. I'm imagining multiple sites built from the same theme and Tina config, where each site has its own content but all sites use the same content structure. This would also avoid the problem you mention of needing to import a schema definition into the main Tina project from a separate content repo.

2. In option 2, how would setting a "path/to/content/root" property as a CLI config differ from using an environment variable in the path property on each collection?

   const pagesCollection: TinaCloudCollection = {
     label: 'Pages',
     name: 'pages',
     path: `${process.env.PATH_TO_CONTENT_ROOT}/content/pages`, // might need NEXT_PUBLIC prefix
     fields: []
   }

   • Would something like the above be functionally equivalent to what you have in mind? (obviously that'd mean the path/to/content/root is set for each individual collection not just once at a config level, but I just want to make sure I'm correctly understanding what you outline in point 2)
   • Are environment variables currently available in schema.ts at build time? I just ran a quick test and those don't seem to be available when running console.log(JSON.stringify(process.env)) in schema.ts, unless they're passed with the build script (e.g. PATH_TO_CONTENT_ROOT=content yarn dev) - that's probably just a part of the standard build process I wasn't aware of not specific to Tina and shouldn't be an issue

The goal I have in mind is a central tina-enabled project that contains separate content folders via git submodules in order for the project to power multiple sites. Each site would be built from the same code repository and the different content for each site would be determined by environment variables. Using git submodules would of course be optional, but it could be handy as it would mean the content folders could each live in their own separate repository but still be accessed from within the central tina-enabled project.

Thanks for sharing all your thoughts on this so far, and please just let us know anyway we can help!

[jamespohalloran]

I think option 1 is really interesting! One unknown I have is how schema migrations might work when the schema & content are detached between repos. In a single repo, it's a bit more simple because changes to the schema & content are pushed up together.

[scottgallant]

See this demo of TinaCMS talking to MDX content located in a remote repo. https://www.loom.com/share/85af4ac6536e4f53bba62e5f191be9c4

If you want to play with this yourself, clone this project and follow the readme.

[wicksipedia]

This is pretty cool, although it looks like the images stay in the main repo and do not get pushed to content repo?

[scottgallant]

Yes, for now this is best used with a 3rd-party media storage provider like one listed here. @jeffsee55 has been thinking on this and might be able to add more detail.

[jeffsee55]

yeah, we don't have a good feel for what you would expect when using Git-backed media in this scenario. It seems clear that the media must be stored in the content repo, so then the question is where does that file get served from? Tina Cloud does have the ability to serve these files so it might be ok to just assume that when using Git-backed media from a separate repo, you'll never have those files in your "website repo" build.