Description
Expected Behavior:
When I deploy the sanity project to the hosted Studio version, I should be able to access and use it at the set subdomain, i.e. your-project.sanity.studio
.
Actual Behavior:
The Studio crashes with error:
Uncaught error: process is not defined
ReferenceError: process is not defined
Error references file /static/sanity.3279a857.js:4558:3169
The studio does not crash locally or from blog domain /studio
.
Steps To Reproduce:
- Follow the steps to Configure locally and deploy from the README
- Ensure the values for the
.env
are referencing your Sanity project - Deploy your project to Sanity via
npx @sanity/cli@dev-preview deploy
- This command must be used instead of
sanity deploy
with the current v3 - Reference: V3 deploy, is it possible yet / are there any docs? sanity#3350 (reply in thread)
- This command must be used instead of
- Log in to your Sanity.io account, select the deployed project and set a subdomain if one isn't already set
- Visit the configured subdomain for the studio
- Observe error:
Uncaught error: process is not defined
Context
This template seems to be only configured for the self-hosted Studio at http://localhost:3000/studio
or your domain /studio
path.
The sanity.config.ts file uses the node process object to access the env file. Since the Studio is a static client-side application, process
is not available there and is therefore undefined
.
Sanity's v2 - v3 migration guide gives a work around for this by setting the appropriate values in your env file that will be bundled and exposed within import.meta.env
. Theses variables must start with SANITY_STUDIO_
in the name.
Possible Solution:
We can accommodate both by conditionally using process.env.NEXT_PUBLIC_SANITY_PROJECT_ID
or import.meta.env.SANITY_STUDIO_PROJECT_ID
depending on if process.env
is defined.
This is a little tricky since we'll have to first check if window
is not 'undefined'
(referencing something like this), so on the client-side version we can set a process attribute that would allow us to check for it in the config file without causing errors.
Within TypeScript will have to reference some interfaces for import.meta
as well, within a env.d.ts
file.
I've got this working on my personal site.