Add support for defaults at schema level

[DawidWraga]

Support defining property default values at the schema level, for more concise inserts and avoiding repetition.

Example:

const todoSchema = z.object({
  id: z.string().default(()=> crypto.randomUUID()),
  text: z.string().default(""),
  completed: z.boolean().default(false),
  createdAt: z.coerce.date().default(()=> new Date()),
  updatedAt: z.coerce.date().default(()=> new Date()),
})

So that you can simply write:

todoCollection.insert({
                text: newTodoText,
              });

Instead of:

  todoCollection.insert({
                // Random temporary id.
                id: Math.floor(Math.random() * 1000000),
                text: newTodoText,
                completed: false,
                created_at: new Date(),
                updated_at: new Date(),
              });

I think only needed for inserts.

[KyleAMathews]

Makes a lot of sense!

[KyleAMathews]

Hmm actually... have you tested this? I think this should just work already — we call .validate on the standard-schema API which it looks like just translates in zod to parseSync — https://github.com/colinhacks/zod/pull/3850/files#diff-c54113cf61ec99691748a3890bfbeb00e10efb3f0a76f03a0fd9ec49072e410aR288

So this very well might already be working 😆

[DawidWraga]

I've added some tests for this (PR) and it's almost working, just had to make this one change and all the runtime tests pass:

export class CollectionImpl {
  insert = (data: T | Array<T>, config?: InsertConfig) => {
    items.forEach((item) => {
      const validatedData = this.validateData(item, `insert`)

      const key = this.getKeyFromItem(validatedData) // <- replaced item with validatedData

      //...
    })
  }
}

However, the type tests are failing because of how z.infer and z.input handle default types (see example).

The insert data param is expecting type generic T which is based on z.infer, but it should instead be z.input. So it currently does not accept partial inputs even when there are defaults.

export class CollectionImpl<
  T extends object = Record<string, unknown>, // <- schema output type
  TKey extends string | number = string | number,
> {
  insert = (
    data: T | Array<T>, // <- expecting schema output, but it should be input instead
    config?: InsertConfig
  ) => {
    //...
  }
}

Current Issues from Test Results:

Type test failure: expectTypeOf<InsertParam>().toEqualTypeOf<TodoInput>() - The collection's insert method expects the full output type (z.infer) but should accept the input type (z.input) which allows optional fields that have defaults. Currently TypeScript errors when trying to insert { text: "task-1" } because it's missing required fields like id, completed, etc., even though these have defaults in the schema.

Possible Solutions

1. Naive Partial Data

Simple and smallest diff footprint, but not very type safe.

export class CollectionImpl {
  insert = (
    data: Partial<T> | Array<Partial<T>>, // <- added Partial to mimic input with minimal changes
    config?: InsertConfig
  ) => {
    // ...
  }
}

2. Add Schema generic to CollectionImpl and use StandardSchemaV1.InferInput

Considerations:

• Handle different schema libraries by using StandardSchemaV1.InferInput instead of z.input
• Handle fallback when no schema is provided

Since createCollection already has TSchema extends StandardSchemaV1, we can just pass that through to CollectionImpl, and then use the standard schema input type if provided.

// fallback to output type when no schema is provided
type CollectionInsertInput<T, TSchema> = TSchema extends StandardSchemaV1
  ? StandardSchemaV1.InferInput<TSchema>
  : T

export class CollectionImpl<
  T extends object = Record<string, unknown>,
  TKey extends string | number = string | number,
  TSchema extends StandardSchemaV1 = StandardSchemaV1, // <- Add schema generic
> {
  insert = (
    data:
      | CollectionInsertInput<T, TSchema>
      | Array<CollectionInsertInput<T, TSchema>>,
    config?: InsertConfig
  ) => {
    // ...
  }
}

// Update createCollection to pass TSchema through:
export function createCollection<
  TExplicit = unknown,
  TKey extends string | number = string | number,
  TUtils extends UtilsRecord = {},
  TSchema extends StandardSchemaV1 = StandardSchemaV1,
  TFallback extends object = Record<string, unknown>,
>(
  options: CollectionConfig<
    ResolveType<TExplicit, TSchema, TFallback>,
    TKey,
    TSchema
  > & { utils?: TUtils }
): Collection<
  ResolveType<TExplicit, TSchema, TFallback>,
  TKey,
  TUtils,
  TSchema // <- Pass TSchema through
> {
  const collection = new CollectionImpl<
    ResolveType<TExplicit, TSchema, TFallback>,
    TKey,
    TSchema // <- Pass TSchema to CollectionImpl
  >(options)
  // ...
}

Pros:

• Fully type-safe input with defaults
• Uses standard schema interface for interop
• Follows existing createCollection pattern (TSchema)
• Fallback to output type when no schema is provided

Cons:

• Requires updating Collection interface and likely many other files that reference it
• Using TInput instead of TSchema (similar to tRPC) could improve type performance

While option 2 requires significantly more changes, I think it's probably worth it since basically every model I use has id createdAt updatedAt so removing that boilerplate from every insert would be very helpful.

Let me know if you have feedback, I'm open to any other alternative suggestions.

[KyleAMathews]

We're making breaking changes left and right so that's not an issue. And type safety plus ensuring defaults work on schemas will be excellent.

It seems like where we're wrong is we don't have this split between input and output types. We just have an output type atm basically where we want both, if you've provided a schema (because only a schema can turn an input into an output).

So I think the needed change is pretty small. We just set the insert/update mutation type to the schema.inferInput type (or just use the explicit type of there's not a schema). Otherwise we use the output type as now.