Sanity Studio V3 - Environment Variables Feature or Bug

[paulwhitaker]

Sanity CLI Environment Variables Issue

Observation

It appears that the Sanity CLI uses both configuration variables found in two configuration files

• sanity.cli.js / ts
• sanity.config.js / ts

This works well as long as you are using strings for values in the sanity.config.js file.
If you use environment variables, the Sanity CLI tool fails.

Expected behavior

When you run the following command in your terminal, your graphql schema is deployed.

sanity graphql deploy

Results

It works if your config file looks like this

...
projectId: 'someStringValue',
...

It fails if you use env variables like this

...
projectId: import.meta.env.SANITY_STUDIO_PROJECT_ID,
...

Possible Cause

The vite server is not running when you execute some CLI commands like, sanity graphql deploy.
Therefore, the env values will not be available.

Is there a best practice?

I don't like using strings in config files. I would prefer to use env vars. Is there a preferred way to handle this?

Thanks in advance for the feedback.

[jacobdanielrose]

I am also having this problem

[paulwhitaker]

I just setup multiple workspaces and realized that it's going to be a huge hassle if the CLI tool is trying to, and unable to, read env vars from sanity.config.js.

After setting up multiple workspaces, I understand why you're doing it that way.

At the moment I have to hard code things that really should be env vars.

Looking at the type definitions for the cli config. Maybe this could be added here in the future.

export declare interface CliConfig {
  api?: CliApiConfig
  project?: {
    basePath?: string
  }
  /**
   * Wraps the Studio in `<React.StrictMode>` root to aid flagging potential problems related to concurrent features (`startTransition`, `useTransition`, `useDeferredValue`, `Suspense`)
   * Can also be enabled by setting `SANITY_STUDIO_REACT_STRICT_MODE="true"|"false"`.
   * It only applies to `sanity dev` in dev mode, it's ignored in `sanity build` and in production.
   * Defaults to `false`
   */
  reactStrictMode?: boolean
  server?: {
    hostname?: string
    port?: number
  }
  graphql?: GraphQLAPIConfig[]
  vite?: (config: any) => any
}

...
export declare interface CliApiConfig {
  projectId?: string
  dataset?: string
}

...

export declare interface GraphQLAPIConfig {
  /**
   * ID of GraphQL API. Only (currently) required when using the `--api` flag
   * for `sanity graphql deploy`, in order to only deploy a specific API.
   */
  id?: string
  /**
   * Name of workspace containing the schema to deploy
   *
   * Optional, defaults to `default` (eg the one used if no `name` is defined)
   */
  workspace?: string
  /**
   * Name of source containing the schema to deploy, within the configured workspace
   *
   * Optional, defaults to `default` (eg the one used if no `name` is defined)
   */
  source?: string
  /**
   * API tag for this API - allows deploying multiple different APIs to a single dataset
   *
   * Optional, defaults to `default`
   */
  tag?: string
  /**
   * Whether or not to deploy a "GraphQL Playground" to the API url - an HTML interface that allows
   * running queries and introspecting the schema from the browser. Note that this interface is not
   * secured in any way, but as the schema definition and API route is generally open, this does not
   * expose any more information than is otherwise available - it only makes it more discoverable.
   *
   * Optional, defaults to `true`
   */
  playground?: boolean
  /**
   * Generation of API to auto-generate from schema. New APIs should use the latest (`gen3`).
   *
   * Optional, defaults to `gen3`
   */
  generation?: 'gen3' | 'gen2' | 'gen1'
  /**
   * Define document interface fields (`_id`, `_type` etc) as non-nullable.
   * If you never use a document type as an object (within other documents) in your schemas,
   * you can (and probably should) set this to `true`. Because a document type _could_ be used
   * inside other documents, it is by default set to `false`, as in these cases these fields
   * _can_ be null.
   *
   * Optional, defaults to `false`
   */
  nonNullDocumentFields?: boolean
}

[MarioGiancini]

@paulwhitaker I've encountered this issue as well, when I was first using the new v3 nextjs blog template: sanity-io/nextjs-blog-cms-sanity-v3#123

My solution was to conditionally use process.env or import.meta.env based on the presence of window , with a couple additions to make Typescript happy:

Create a file in the root of your project called env.d.ts with the following:

// env.d.ts
/// <reference types="vite/client" />

interface ImportMetaEnv {
  readonly SANITY_STUDIO_DATASET: string
  readonly SANITY_STUDIO_PROJECT_ID: string
  readonly SANITY_STUDIO_PROJECT_TITLE: string
  readonly SANITY_STUDIO_PUBLIC_PREVIEW_SECRET: string
  // more env variables...
}
interface ImportMeta {
  readonly env: ImportMetaEnv
}

Then in your sanity.config.ts file:

/**
 * Sanity deployed studio from sanity.studio can't access process.env since the Studio
 * is a static client-side application and these variables will be bundled. Therefore,
 * you would see an error like "process is not defined." On the self-hosted version, both
 * locally and from the configured public domain, process is available via Next.js.
 * 
 * In the instance we want to access from sanity.studio subdomain, we need use the
 * exposed "import.meta.env" instead of "process.env".
 * @see https://beta.sanity.io/docs/platform/studio/v2-to-v3/environment-variables
 */

/**
 * Method for placing process in the window if this is the client-side version of studio,
 * to prevent process undefined error.
 */
if (typeof window !== 'undefined' && !('process' in window)) {
  // @ts-ignore
  window.process = {}
}

/**
 * Put access to the self-hosted Sanity Studio in it's own path, 
 * but from Sanity subdomain put it off the root.
 */
const basePath = process.env ? '/studio' : '/'

export default createConfig({
  basePath,
  projectId: process.env ? process.env.NEXT_PUBLIC_SANITY_PROJECT_ID : import.meta.env.SANITY_STUDIO_PROJECT_ID,
  dataset: process.env ? process.env.NEXT_PUBLIC_SANITY_DATASET : import.meta.env.SANITY_STUDIO_DATASET,
  title: process.env ? process.env.NEXT_PUBLIC_SANITY_PROJECT_TITLE : import.meta.env.SANITY_STUDIO_PROJECT_TITLE,
  schema: {
    // If you want more content types, you can add them to this array
    types: [],
  },
  // plugins and rest of config...
  plugins: [],
  // ...
})

[genox]

Am I right to assume that you are not building a static artefact but instead run sanity self-hosted with sanity start?

I think I have a similar issue where I would like to deploy the built artefact in nextjs' public folder but I can't get the basePath to be baked in. I made sure I use the proper .env file while building it in CI but it is ignored:

basePath: import.meta.env.SANITY_STUDIO_ENV === 'production' ? '/sanity' : '/',

I tried your solution with conditional vars based on process, but that didn't work either. But I assume this is because process.env is not populated during build.

It looks like the env var isn't set while building.

Or maybe I am missing the tree for the forest. But I assumed this should work. :)

edit:

Weird thing is, even if I set basePath to a static string it doesn't get baked into the file paths, even when I build sanity locally. All asset links point to the root. I assume there is a larger thing at play here.

[genox]

After trying to get a self-hosted version of sanity deployed for a while now and falling back to studio deployments, I would be very thankful if the documentation team could look into providing a working example of v3 being built and deployed in CI environments where all parts of the process rely on env vars defined in the correct way and picked up.

If a conditional hack is required (process.env vs vite, etc), please provide an official way for us to follow through or, even better, a way that hides this fact by abstracting it.

basically, all I would like to do is build sanity with a custom base path, but that base path isn't picked up during build. and env vars aren't picked up by the cli config file the same way that the "regular" app would require it. That is a little bit confusing.