Should Sanity schema documents use .jsx/.tsx or only for dynamic schemas?

Good question! In Sanity, you can use .js, .jsx, .ts, or .tsx for schema files, and the choice mostly comes down to whether you're using TypeScript and personal/team preference. There's no strict requirement to use one over the other for "dynamic" vs "static" schemas.

Here's the practical breakdown:

Use .ts or .tsx if:

• You're using TypeScript in your project (which is increasingly common)
• You want type safety and autocomplete when defining schemas
• You're using helper functions like defineType and defineField that provide better TypeScript inference

Use .js or .jsx if:

• You're working in a JavaScript-only project
• Your team prefers plain JavaScript

Regarding .jsx vs .tsx specifically: The .jsx/.tsx extensions are technically for files containing JSX syntax (React components). Schema files are typically just JavaScript/TypeScript objects, so they don't need the x suffix. However, many projects use .tsx for all TypeScript files as a convention, and it works fine.

Best practice recommendation:

• If using TypeScript: Use .ts for schema files (or .tsx if that's your project convention)
• If using JavaScript: Use .js for schema files

The schema-as-code approach in Sanity treats all schemas as code files, and the extension doesn't change how Sanity processes them. What matters more is consistency across your project.

Example with TypeScript (recommended for type safety):

// schemas/product.ts
import { defineType, defineField } from 'sanity'

export default defineType({
  name: 'product',
  type: 'document',
  fields: [
    defineField({
      name: 'title',
      type: 'string'
    })
  ]
})

The main advantage of TypeScript is that you can leverage Sanity TypeGen to generate types from your schemas, giving you end-to-end type safety from content model to query results.

TL;DR: Use .ts for TypeScript projects, .js for JavaScript projects. The "dynamic" nature of a schema doesn't change which extension to use—consistency across your codebase matters more.