feat: Drizzle 1.0 type safety fixes

[austinm911]

Drizzle 1.0 Support

Human Summary

This is entirely claude generated so buyer beware, however I am migrating a project to Drizzle 1.0 beta and this seems to mostly work, except for some missing types in a JSON field.

I figured I'd keep this up in draft form in case you'd like to reference anything or take over to clean up.

⚠️ Draft PR

Summary

This PR adds support for Drizzle ORM 1.0 (currently ^1.0.0-beta.10), which introduced significant internal changes to column type representation.

Status: All 633 tests passing, 0 type errors. Working in my production app with Drizzle 1.0 beta, generating correct Zero schemas with proper types.

What Changed in Drizzle 1.0

Drizzle 1.0 changed how column types are represented internally:

Aspect	Drizzle 0.x	Drizzle 1.0
dataType	Simple: 'string', 'number'	Compound: 'string uuid', 'object date'
columnType	In column._ object	Direct property on column
$type<T>()	Sets _.$type	Sets _.data directly
Relations	relations() helper	defineRelations() API

Changes Made

Core Type System (src/)

• New type predicates: IsTimestampDataType, IsBigIntDataType, IsStringNumericDataType to detect Drizzle 1.0's compound dataTypes
• IsExactType helper: Distinguishes default types (Date, string, bigint) from explicit $type<T>() overrides
• Runtime utilities: extractBaseType() and mapDrizzle1DataTypeToZero() for parsing compound dataTypes
• Updated CustomType/ZeroMappedCustomType: Handle new column structure while preserving backwards compatibility

Type Resolution (src/cli/)

• Fixed ReadonlyJSONValue being incorrectly expanded (now uses UseAliasDefinedOutsideCurrentScope flag first)

Previously Unsupported Types

These types now work in Drizzle 1.0 (they have valid compound dataTypes):

• interval, cidr, macaddr, inet → string
• point, line, geometry → json

Type Mapping Logic

Drizzle 1.0 dataType    →  Zero Type
─────────────────────────────────────
'string'                →  string
'string uuid'           →  string
'string timestamp'      →  number (!)
'string date'           →  number (!)
'string numeric'        →  number (!)
'number'                →  number
'number int32'          →  number
'bigint int64'          →  number
'object date'           →  number
'object json'           →  json
'array point'           →  json
'boolean'               →  boolean
'custom'                →  (fallback to getSQLType())

Key insight: $type<T>() overrides are preserved. If you use timestamp().$type<ISODateString>(), the custom type is kept rather than being converted to number.

Testing

pnpm test  # 633 tests passing, 0 type errors

New tests added:

• tests/drizzle-1.0.test.ts - Compound dataType utility tests
• Type-level tests in tests/types.test.ts for timestamp/bigint/numeric mapping

Questions for Maintainer

1. Backwards compatibility: The changes attempt to support both Drizzle 0.x and 1.0 column structures. Is this the right approach, or should we drop 0.x support?

2. defineRelations() vs relations(): Both APIs are supported. The old relations() still works but defineRelations() is the new recommended approach.

3. Type coercion: Timestamps/dates/bigints all map to number in Zero. This matches how Zero stores these values. Is this correct?

4. Custom type preservation: When $type<T>() is used, we preserve the custom type instead of converting. This seemed like the right UX but want to confirm.

How I Tested

• Running in a production app with Drizzle 1.0 beta
• Schema generation produces correct types
• Zero client works with generated schemas
• All existing tests pass

---

Happy to address any feedback or concerns. This is based on the earlier 0xcadams/drizzle-beta branch with additional fixes for type safety issues discovered during testing.

[0xcadams]

I am sorry but this is such a massive PR, it’s going to be very hard for me to review this and merge. I will use it as a reference but 4k lines changing won’t be something I can review meaningfully.

[austinm911]

Absolutely no worries! I did not mean to overwhelm or expect you to review much. I just figured that if it's helpful in any way as a reference, then great. Thanks for your work !