Get help on Discord

Issues with deploying GraphQL after upgrading from V2 to V3 Sanity

6 replies
Last updated: Feb 9, 2023
Hello 👋
Since the upgrade from V2 to V3 sanity, I'm having issues running 
sanity graphql deploy
,

production: Could not resolve source `production`:
        - An error occurred while resolving `tools` from production: Cannot read properties of undefined (reading 'PRODUCTION'
I have tried searching through different similar threads, although couldn't figure out where the issue is.
AI Update

I can see you're hitting a specific error related to import.meta.env.PRODUCTION after upgrading to Sanity v3. This is a common issue that happens when your configuration files try to use environment variables that aren't available in the Node.js context where sanity graphql deploy runs.

The problem is that import.meta.env is a Vite-specific feature that only works in the browser/build context of your Studio, but the GraphQL deploy command runs in Node.js, where import.meta.env is undefined. When your config tries to read import.meta.env.PRODUCTION, it fails because import.meta.env itself is undefined.

The Fix

You need to update your sanity.config.ts (or .js) file to handle this properly. Here are the most common solutions:

Option 1: Use process.env instead (recommended)

Replace import.meta.env.PRODUCTION with process.env.NODE_ENV:

import { defineConfig } from 'sanity'

export default defineConfig({
  name: 'default',
  title: 'My Studio',
  projectId: 'your-project-id',
  dataset: process.env.NODE_ENV === 'production' ? 'production' : 'development',
  // rest of your config
})

Option 2: Add a fallback check

If you need to support both contexts, add a check:

const isProduction = typeof import.meta !== 'undefined' 
  ? import.meta.env?.PRODUCTION 
  : process.env.NODE_ENV === 'production'

export default defineConfig({
  dataset: isProduction ? 'production' : 'development',
  // rest of your config
})

Option 3: Remove conditional logic for GraphQL

If you're only deploying GraphQL for production, you can hardcode it:

export default defineConfig({
  dataset: 'production',
  // rest of your config
})

Why This Happens

In v2, the configuration was simpler and didn't use Vite. V3 introduced Vite as the build tool, which provides import.meta.env for the Studio UI. However, CLI commands like sanity graphql deploy still run in Node.js and don't have access to Vite's environment variables.

The error message "Cannot read properties of undefined (reading 'PRODUCTION')" literally means it's trying to access undefined.PRODUCTION because import.meta.env is undefined in the Node.js context.

After making these changes, your sanity graphql deploy command should work properly!

sanity.cli.js

// sanity.cli.js
import {defineCliConfig} from 'sanity/cli'
import * as dotenv from 'dotenv'

export default defineCliConfig({
  api: {
    projectId: 'XXXX', // replace value with your own
    dataset: 'dev' // replace value with your own
  },
  graphql: [
    {
      id: "production",
      workspace: "production",
    },
    {
      id: "dev",
      workspace: "dev",
    },
  ],
})

sanity.config.js

// sanity.config.js
import { defineConfig } from "sanity";
import { deskTool } from 'sanity/desk'
import schemas from './schemas/schema'
import { table } from '@sanity/table';
import { colorInput } from "@sanity/color-input";
import deskStructure from './sidebar'
import { visionTool } from '@sanity/vision'
import * as dotenv from 'dotenv'

export default defineConfig([{
  title: "XXX Dev",
  projectId: "XXX ",
  dataset: "dev",
  name: "dev",
  basePath: '/dev',
  plugins: [deskTool({structure: deskStructure}),
    visionTool(),
    table(),
    colorInput()],
    tools: (prev) => {
      // 👇 Uses environment variables set by Vite in development mode
      if (import.meta.env.DEV) {
        return prev
      }
      return prev.filter((tool) => tool.name !== 'vision')
},
  schema: {
    types: schemas,
  },
  document: {
    newDocumentOptions: (prev, { creationContext }) => {
      if (creationContext.type === 'global') {
        return prev.filter((templateItem) => templateItem.templateId != 'settings')
      }
      return prev
    },
    actions: (prev, { schemaType }) => {
      if (schemaType === 'settings') {
        return prev.filter(({ action }) => !['unpublish', 'delete','duplicate'].includes(action))
      }
      return prev
    },
  },
},
{
  title: "XXX Prod",
  projectId: "XXX",
  dataset: "production",
  name: "production",
  basePath: '/production',
  plugins: [deskTool({structure: deskStructure}),
    visionTool(),
    table(),
    colorInput()],
    tools: (prev) => {
      // 👇 Uses environment variables set by Vite in development mode
      if (import.meta.env.PRODUCTION) {
        return prev
      }
      return prev.filter((tool) => tool.name !== 'vision')
},
  schema: {
    types: schemas,
  },
  document: {
    newDocumentOptions: (prev, { creationContext }) => {
      if (creationContext.type === 'global') {
        return prev.filter((templateItem) => templateItem.templateId != 'settings')
      }
      return prev
    },
    actions: (prev, { schemaType }) => {
      if (schemaType === 'settings') {
        return prev.filter(({ action }) => !['unpublish', 'delete','duplicate'].includes(action))
      }
      return prev
    },
  },
}]);

Would anyone have any thoughts on this? 🙈 🙏
I don’t see anything obviously wrong, but i also don’t use the rplugin. I know they moved from 
process.env
👉 
import.meta.env
which you seem to be using. Maybe pop open sanity graphql and peek under the hood? Are you on the latest version?
Are you using a tag when deploying? Seems similar to what was happening here .
Thanks both. It was the 
process.env
and 
import.meta.env
This post helped:

https://sanity-io-land.slack.com/archives/C9Z7RC3V1/p1671819526675779
Changing 
import.meta.env.PRODUCTION
to 
import.meta.PRODUCTION
allowed me to deploy graphql. I shall have a play to get the pipelines up and running 🙂

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Get started for freeExplore the demo

Was this answer helpful?