How to structure your code repository in a Sanity.io project

Written by Knut Melvær

You have started a Sanity project and have configured your schemas and published some content to the API. You are now ready to make a frontend, an app, or a service that makes use of it. Even though you can use Sanity.io as a general API for all sorts of things, it makes sense in some cases to keep the Sanity Studio close to those services that make use of it. Moreover, if you think of it, the Studio is just another frontend to your Sanity API.

There are probably many ways to approach this, but the pattern we have seen the most is to structure your project in a monorepo. In fact, we do it ourselves with the Studio and the many packages that can be used separate from it. Of course, you should consider pros-and-cons of multi- or monorepos, but for a typical project with a studio, a frontend web- or app project with perhaps a simple service, we think it makes sense. It means that you have version controll over your schemas. Which is a good thing. It also means that you can include the content studio in a Continious Integration flow, integrating it with other apps.

There is little magic to making a monorepo, in essence, it just a simple folder structure: