Skip to content
Sanity
Get started
  • Sanity Studio - Flexible editing environment
  • Content Lake - Real-time database
  • Developer experience - Tooling you love
  • Structured content - The philosophy behind Sanity
  • Review changes - View edits & rollback instantly
  • Image pipeline - On-demand transformations
  • E-commerce - Better shopping experiences
  • Marketing sites - Control your story
  • Products & services - Innovate and automate
  • Mobile apps - Content backend for every OS
  • Aether - Unique digital shopping experience
  • Morning Brew - Omnichannel media distribution
  • InVision - Delivering exceptional customer experiences
  • DataStax - Personalization for global audience
  • React
  • Gatsby
  • Next
  • Nuxt
  • Eleventy
  • Netlify
  • Vercel
  • Algolia
  • Documentation
  • Reference
  • Guides
  • Resource library
  • Headless CMS
  • Tools & plugins
  • Project showcase
  • Schemas & snippets
  • Agency partners
  • Technology partners
  • Get support
  • Share your work
  • 5 Disadvantages Of Wordpress That Are Holding You Back
EnterprisePricing
Contact salesLog inGet started
Published August 20th 2018

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

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, and app, or a service that takes use of it. But how to structure your code?

Knut Melvær

Principal Developer Marketing Manager

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:

project-folder/
├── studio/
│   ├── config/
│   ├── plugins/
│   ├── schemas/
│   ├── static/
│   ├── .gitignore
│   ├── README.md
│   ├── package.json
│   └── sanity.json
├── frontend/
│   ├── components/
│   ├── lib/
│   ├── pages/
│   ├── static/
│   ├── .gitignore
│   ├── README.md
│   └── package.json
├── services/
│   ├── rss-feed/
│   │   ├── .gitignore
│   │   ├── index.js
│   │   ├── package.js
│   │   └── README.md
│   └── README.md
├── .gitignore
└── README.md

In this case, dependencies are installed in each separate folder. So you'll have to start the apps and target the folders in your build system. If the project grows and some of your packages is to be published to npm or the like, you can use monorepo managing tools like Lerna, to make it easier to keep track of versioning and to bootstrap.

Since we have written Sanity Studio in React, this structure also allows for sharing UI-components, CSS and so on across projects.

Still not sure how to structure the code in your project? Join our Slack and ask us!

Platform

Structured ContentDeveloper experienceContent LakeSanity StudioSecurity & Compliance
  • Sanity vs Contentful
  • Sanity vs Strapi
  • Sanity vs Wordpress
  • Sanity vs Adobe Experience Manager
  • Sanity vs Hygraph
  • Sanity vs Sitecore
  • Sanity vs Storyblok
  • Sanity vs Contentstack
  • Sanity vs Prismic
  • Sanity vs Drupal
  • Sanity vs ButterCMS

Resources

Documentation
  • React Blog
  • Gatsby Blog
  • Next.js Landing Pages
  • Progressive Web Application
  • Single Page Application
  • Svelte & Typescript App
  • Vue & Tailwind Blog
  • Developer Portfolio Templates
  • Form validation with Yup
  • Live Preview with Next.js and Sanity.io
Resource library
  • Agency partners
  • Technology partners
  • Blog Template
  • Personal Website Template
  • Developer Portfolio Templates
  • All Templates
Case Studies
  • Headless CMS
  • What is an API CMS
  • Static Sites 101
  • Headless SEO
  • Localization
  • GraphQL vs REST
  • What is a DXP?
  • Typescript 101
  • Content as a Service
  • Ecommerce SEO
  • React CMS
  • Next.JS CMS
  • CMS for Shopify
  • Content platform
  • Multilingual CMS
  • Static Site CMS
  • Gatsby CMS
  • Node CMS
  • E-commerce CMS
  • Vue CMS
  • Angular CMS
  • GraphQL CMS
  • Newspaper CMS
  • Magazine CMS
  • CMS for apps
  • Remix CMS

Company

Contact SalesEnterpriseCareersTerms of ServiceAccessibility Statement

Stay connected

  • GitHub
  • Slack
  • Twitter
  • YouTube
  • Stack Overflow
  • Blog RSS
  • Newsletter
©Sanity 2023