Feedback: Config API

[kmelve]

Sanity Studio v3 introduces a new Config API.

Let us know how it works for you:

• How has the transition from sanity.json to sanity.config.(js|ts) worked out for you?
• Is there anything unclear?
• Is there anything that you expect to work that doesn't?
• Are there things you can do now that you couldn't do before?

[plsrd]

Really loving the ease of use with the new Config API! The only issue I ran into was migrating my custom auth provider. Following the example given, I get the error: Uncaught error: import not found: createAuthStore

[joshuaellis]

This might not be the best place for this, but it's worth mentioning that in the documentation you should definitely include how to get the ENV variables because I imagine a lot of people might not be familiar with vite's import.meta.env (https://vitejs.dev/guide/env-and-mode.html) especially as it was process.env in sanity v2.

[wesselvanree]

Looks like the Vite envPrefix option is set to SANITY_STUDIO_ in this file (this prefix is also used in v2). So you still have to use the SANITY_STUDIO_ prefix instead of VITE_ to access environment variables in the Studio at import.meta.env.SANITY_STUDIO_YOUR_ENV_VAR.

[theycallmeswift]

Good catch @wesselvanree. The type definitions are not working properly, but I can access the env as expected.

To resolve the error (property 'env' does not exist on type 'importmeta'), I added the following type definition and cast meta accordingly:

interface ImportMetaWithEnv extends ImportMeta {
  env?: {
    [key: string]: string;
  };
}

const secret = (import.meta as ImportMetaWithEnv).env?.SANITY_STUDIO_MY_SECRET as string;

[wesselvanree]

I'm currently using an env.d.ts file in the project root as described in the Env Variables and Modes Vite docs. I found that to be a lot easier to work with.

[theycallmeswift]

Good call. You can also just add /// <reference types="vite/client" /> to the top of your file and ignore the custom type all together since it already had a generic catchall on key

[kmelve]

Hi all! We just published migration documentation on this. Let us know if it covers everything!

[unitof]

For schemas, wasn't totally clear from the new docs that all I had to do was delete my v2 schemas/schema.js and then directly import my document types. Docs actually made it sound more complicated, like I had to manually flatten and rewrite my schemas directly into sanity.config.js.

I like this much better!

import { createConfig } from 'sanity'

import book from './schemas/book'
import author from './schemas/author'

export default createConfig({
  ...
  schema: {
    types: [
      book,
      author
    ],
  },
  ...
})

[mmgj]

Thank you for the feedback!
I agree that writing the schema type directly into the schema.types-array is not a very realistic scenario, but it does have the advantage of showing the syntax for schemas, and how it remains the same as in v2, without introducing another file to the example.

Would the example be made clearer if the schema was declared in the same file but outside of the createConfig() function, or would that just make it more obtuse, would you say?
I.e.

// /sanity.config.js (.ts)
import { createConfig } from 'sanity'
import { deskTool } from 'sanity/desk'

const book = {
        name: 'book',
        type: 'document',
        title: 'Book',
        fields: [
          {
            name: 'title',
            type: 'string',
            title: 'Book title'
          }
        ]
      }
      
export default createConfig({
  name: 'default',
  title: 'My Cool Project',
  projectId: 'my-project-id',
  dataset: 'production',
  plugins: [deskTool()],
  schema: {
    types: [
      book,
    ]
   },
})

[unitof]

Thanks @mmgj! I don't think it was the direct inclusion of the schema object that caused my confusion.

The issue was that it was unclear I could just get rid of schema.js entirely! I thought I had to keep it but change how it formed the export.

Maybe my example is simpler than most but I think it'd be helpful to mention in many cases (like mine, based originally off the Movies example) you can simply build an object of all your document types. No more flattening or processing needed!

[mustaqimarifin]

I kept my schema folder as is and export all as schemaTypes into config.ts .. deep nesting gets annoying fast!

studio.mp4

V3 markdown plugin seems great except it can't seem to max the editor without it blocking & glitching out? Any tips welcome..

But i'm wondering if GROQ is working with V3 yet, cuz I can't seem to run any query from vscode. Hoping theres a workaround

Thanks!

[peeke]

I sort off expected (hoped) this pattern to work for defining plugins as well:

// Example using the callback function with some conditional logic
tools: (prev, {currentUser}) => {

My current use case would be showing the vision plugin to admin users only.

[SR-Sujon]

Whenever i tried to run sanity v3 from the terminal. It says:
"Failed to resolve import "./schemas" from "sanity.config.js".
Why isn't it wroking?

[RomaLinks]

Same here

[KingsIke]

Type error: Module '"sanity"' has no exported member 'defineConfig'.

4 | import { visionTool } from '@sanity/vision'
5 | import { schemaTypes } from './schemas'

6 | import { defineConfig } from 'sanity'
| ^
7 |
8 | export default defineConfig({
9 | name: 'default',