Skip to content

fix(codegen-ts): @autoSet and plain field.timestamp now honor timestampMode - #281

Merged
dmealing merged 1 commit into
mainfrom
fix/autoset-timestamp-mode
Aug 9, 2026
Merged

fix(codegen-ts): @autoSet and plain field.timestamp now honor timestampMode#281
dmealing merged 1 commit into
mainfrom
fix/autoset-timestamp-mode

Conversation

@dmealing

@dmealing dmealing commented Aug 9, 2026

Copy link
Copy Markdown
Member

Companion to #279 (the serial-identity fix, same adopting-project report). timestampMode:"date" worked for the base Drizzle column but not for @autoset's $defaultFn (hardcoded .toISOString() into a Date-typed column — hard tsc failure) or for zod-validators.ts's FIELD_SUBTYPE_TIMESTAMP case (z.string() regardless of mode, even for plain non-autoSet fields). Both now branch on ctx.timestampMode; unchanged for every existing string-mode caller. bun test: 1040 pass, 0 fail. tsc clean.

…mpMode

timestampMode:"date" already worked for the base Drizzle column type
(column-mapper.ts's mapColumnType) but two call sites still hardcoded
string-shaped output regardless:

1. drizzle-schema.ts's @autoset suffix always emitted
   .$defaultFn(() => new Date().toISOString()) -- a string -- into a column
   that's mode:"date" (expects a Date), a hard tsc failure
   ("Type 'string' is not assignable to type 'Date | SQL<unknown>'"),
   cascading into every generated insert/update query touching the field.

2. zod-validators.ts's FIELD_SUBTYPE_TIMESTAMP case in zodFieldExpr, plus
   its own 3 separate @autoset call sites, always emitted z.string() /
   a string-returning transform -- disagreeing with the Drizzle column even
   for a PLAIN (non-autoSet) timestamp field once timestampMode:"date" is
   set, not just @autoset ones.

Both now branch on ctx.timestampMode: "date" -> new Date() / z.date()
(unchanged), "string" (default) -> the original .toISOString()/z.string()
behavior, byte-identical to before for every existing caller that doesn't
opt in.

field.date/field.time stay z.string() unconditionally -- calendar
date/time-of-day are inherently string-shaped on the wire, not governed by
timestampMode (which is specifically about field.timestamp's instant
representation).

Not touched: zodScalarFor() (used for field.map's valueType) still returns
z.string() for a timestamp-typed map value regardless of timestampMode --
narrower, unverified edge case, flagged rather than guessed at.

Reported and reproduced against an adopting project: real entity, real
`meta gen`, real `tsc --noEmit` failure before this fix, clean after.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C7jsHCMNVmaXu883UFsh1e
@dmealing
dmealing merged commit e7c4828 into main Aug 9, 2026
1 check passed
@dmealing
dmealing deleted the fix/autoset-timestamp-mode branch August 9, 2026 03:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant