v0.0.2-alpha.16

Released all 12 packages at 0.0.2-alpha.16 in lockstep (nextly, create-nextly-app, and 10 @nextlyhq/* packages).

What's changed

@nextlyhq/adapter-drizzle

Patch Changes

• #52 9bc10b6 Thanks @aqib-rx! - Fix update operation failed on table '<table>': value.toISOString is not a function when saving a Single document or a component instance that includes a date field. JSON request bodies deliver date values as ISO strings (e.g. "2026-05-20T12:22:29.417Z"), but Drizzle binds timestamp columns by calling .toISOString() on the bound value -- so an unmodified string travelling through the adapter blows up at the driver layer. CollectionMutationService already coerced date strings into Date objects inline at every write site, but the equivalent step was missing from SingleMutationService.update and from ComponentMutationService.serializeComponentRow (which feeds every insert / update path in the component service via buildInsertRow and direct calls).

  A new coerceDateFieldsToDate(data, fields) helper in shared/lib/field-transform.ts mutates the row in place, converting string values for field.type === "date" columns into Date objects. Existing Date, null, and undefined values pass through untouched, so the function is idempotent and safe to call on rows that were coerced upstream. The signature accepts a structural ReadonlyArray<{ name?: string; type?: string }> so the same helper covers both FieldConfig[] (singles, components) and the runtime FieldDefinition[] (collections). The helper is wired into single-mutation-service.update before snake-casing the row and into component-mutation-service.serializeComponentRow before column mapping. The six inline copies of the same coercion block in collection-mutation-service.ts were collapsed onto the shared helper as part of the same change so there is one implementation across all three domains. Result: PATCH /admin/api/singles/<slug> with a date field, inserts / updates on components with date fields, and the existing collection flows that already worked all succeed against Postgres, MySQL, and SQLite. Unit tests cover the helper's coercion, idempotency, null / undefined pass-through, and no-touch behaviour for non-date fields.

@nextlyhq/adapter-mysql

Patch Changes

• #52 9bc10b6 Thanks @aqib-rx! - Fix update operation failed on table '<table>': value.toISOString is not a function when saving a Single document or a component instance that includes a date field. JSON request bodies deliver date values as ISO strings (e.g. "2026-05-20T12:22:29.417Z"), but Drizzle binds timestamp columns by calling .toISOString() on the bound value -- so an unmodified string travelling through the adapter blows up at the driver layer. CollectionMutationService already coerced date strings into Date objects inline at every write site, but the equivalent step was missing from SingleMutationService.update and from ComponentMutationService.serializeComponentRow (which feeds every insert / update path in the component service via buildInsertRow and direct calls).

  A new coerceDateFieldsToDate(data, fields) helper in shared/lib/field-transform.ts mutates the row in place, converting string values for field.type === "date" columns into Date objects. Existing Date, null, and undefined values pass through untouched, so the function is idempotent and safe to call on rows that were coerced upstream. The signature accepts a structural ReadonlyArray<{ name?: string; type?: string }> so the same helper covers both FieldConfig[] (singles, components) and the runtime FieldDefinition[] (collections). The helper is wired into single-mutation-service.update before snake-casing the row and into component-mutation-service.serializeComponentRow before column mapping. The six inline copies of the same coercion block in collection-mutation-service.ts were collapsed onto the shared helper as part of the same change so there is one implementation across all three domains. Result: PATCH /admin/api/singles/<slug> with a date field, inserts / updates on components with date fields, and the existing collection flows that already worked all succeed against Postgres, MySQL, and SQLite. Unit tests cover the helper's coercion, idempotency, null / undefined pass-through, and no-touch behaviour for non-date fields.

• Updated dependencies [9bc10b6]:

  • @nextlyhq/adapter-drizzle@0.0.2-alpha.16

@nextlyhq/adapter-postgres

Patch Changes

• #52 9bc10b6 Thanks @aqib-rx! - Fix update operation failed on table '<table>': value.toISOString is not a function when saving a Single document or a component instance that includes a date field. JSON request bodies deliver date values as ISO strings (e.g. "2026-05-20T12:22:29.417Z"), but Drizzle binds timestamp columns by calling .toISOString() on the bound value -- so an unmodified string travelling through the adapter blows up at the driver layer. CollectionMutationService already coerced date strings into Date objects inline at every write site, but the equivalent step was missing from SingleMutationService.update and from ComponentMutationService.serializeComponentRow (which feeds every insert / update path in the component service via buildInsertRow and direct calls).

  A new coerceDateFieldsToDate(data, fields) helper in shared/lib/field-transform.ts mutates the row in place, converting string values for field.type === "date" columns into Date objects. Existing Date, null, and undefined values pass through untouched, so the function is idempotent and safe to call on rows that were coerced upstream. The signature accepts a structural ReadonlyArray<{ name?: string; type?: string }> so the same helper covers both FieldConfig[] (singles, components) and the runtime FieldDefinition[] (collections). The helper is wired into single-mutation-service.update before snake-casing the row and into component-mutation-service.serializeComponentRow before column mapping. The six inline copies of the same coercion block in collection-mutation-service.ts were collapsed onto the shared helper as part of the same change so there is one implementation across all three domains. Result: PATCH /admin/api/singles/<slug> with a date field, inserts / updates on components with date fields, and the existing collection flows that already worked all succeed against Postgres, MySQL, and SQLite. Unit tests cover the helper's coercion, idempotency, null / undefined pass-through, and no-touch behaviour for non-date fields.

• Updated dependencies [9bc10b6]:

  • @nextlyhq/adapter-drizzle@0.0.2-alpha.16

@nextlyhq/adapter-sqlite

Patch Changes

• #52 9bc10b6 Thanks @aqib-rx! - Fix update operation failed on table '<table>': value.toISOString is not a function when saving a Single document or a component instance that includes a date field. JSON request bodies deliver date values as ISO strings (e.g. "2026-05-20T12:22:29.417Z"), but Drizzle binds timestamp columns by calling .toISOString() on the bound value -- so an unmodified string travelling through the adapter blows up at the driver layer. CollectionMutationService already coerced date strings into Date objects inline at every write site, but the equivalent step was missing from SingleMutationService.update and from ComponentMutationService.serializeComponentRow (which feeds every insert / update path in the component service via buildInsertRow and direct calls).

  A new coerceDateFieldsToDate(data, fields) helper in shared/lib/field-transform.ts mutates the row in place, converting string values for field.type === "date" columns into Date objects. Existing Date, null, and undefined values pass through untouched, so the function is idempotent and safe to call on rows that were coerced upstream. The signature accepts a structural ReadonlyArray<{ name?: string; type?: string }> so the same helper covers both FieldConfig[] (singles, components) and the runtime FieldDefinition[] (collections). The helper is wired into single-mutation-service.update before snake-casing the row and into component-mutation-service.serializeComponentRow before column mapping. The six inline copies of the same coercion block in collection-mutation-service.ts were collapsed onto the shared helper as part of the same change so there is one implementation across all three domains. Result: PATCH /admin/api/singles/<slug> with a date field, inserts / updates on components with date fields, and the existing collection flows that already worked all succeed against Postgres, MySQL, and SQLite. Unit tests cover the helper's coercion, idempotency, null / undefined pass-through, and no-touch behaviour for non-date fields.

• Updated dependencies [9bc10b6]:

  • @nextlyhq/adapter-drizzle@0.0.2-alpha.16

@nextlyhq/admin

Patch Changes

• #52 9bc10b6 Thanks @aqib-rx! - Fix update operation failed on table '<table>': value.toISOString is not a function when saving a Single document or a component instance that includes a date field. JSON request bodies deliver date values as ISO strings (e.g. "2026-05-20T12:22:29.417Z"), but Drizzle binds timestamp columns by calling .toISOString() on the bound value -- so an unmodified string travelling through the adapter blows up at the driver layer. CollectionMutationService already coerced date strings into Date objects inline at every write site, but the equivalent step was missing from SingleMutationService.update and from ComponentMutationService.serializeComponentRow (which feeds every insert / update path in the component service via buildInsertRow and direct calls).

  A new coerceDateFieldsToDate(data, fields) helper in shared/lib/field-transform.ts mutates the row in place, converting string values for field.type === "date" columns into Date objects. Existing Date, null, and undefined values pass through untouched, so the function is idempotent and safe to call on rows that were coerced upstream. The signature accepts a structural ReadonlyArray<{ name?: string; type?: string }> so the same helper covers both FieldConfig[] (singles, components) and the runtime FieldDefinition[] (collections). The helper is wired into single-mutation-service.update before snake-casing the row and into component-mutation-service.serializeComponentRow before column mapping. The six inline copies of the same coercion block in collection-mutation-service.ts were collapsed onto the shared helper as part of the same change so there is one implementation across all three domains. Result: PATCH /admin/api/singles/<slug> with a date field, inserts / updates on components with date fields, and the existing collection flows that already worked all succeed against Postgres, MySQL, and SQLite. Unit tests cover the helper's coercion, idempotency, null / undefined pass-through, and no-touch behaviour for non-date fields.

• Updated dependencies [9bc10b6]:

  • @nextlyhq/ui@0.0.2-alpha.16

create-nextly-app

Patch Changes

• #52 9bc10b6 Thanks @aqib-rx! - Fix update operation failed on table '<table>': value.toISOString is not a function when saving a Single document or a component instance that includes a date field. JSON request bodies deliver date values as ISO strings (e.g. "2026-05-20T12:22:29.417Z"), but Drizzle binds timestamp columns by calling .toISOString() on the bound value -- so an unmodified string travelling through the adapter blows up at the driver layer. CollectionMutationService already coerced date strings into Date objects inline at every write site, but the equivalent step was missing from SingleMutationService.update and from ComponentMutationService.serializeComponentRow (which feeds every insert / update path in the component service via buildInsertRow and direct calls).

  A new coerceDateFieldsToDate(data, fields) helper in shared/lib/field-transform.ts mutates the row in place, converting string values for field.type === "date" columns into Date objects. Existing Date, null, and undefined values pass through untouched, so the function is idempotent and safe to call on rows that were coerced upstream. The signature accepts a structural ReadonlyArray<{ name?: string; type?: string }> so the same helper covers both FieldConfig[] (singles, components) and the runtime FieldDefinition[] (collections). The helper is wired into single-mutation-service.update before snake-casing the row and into component-mutation-service.serializeComponentRow before column mapping. The six inline copies of the same coercion block in collection-mutation-service.ts were collapsed onto the shared helper as part of the same change so there is one implementation across all three domains. Result: PATCH /admin/api/singles/<slug> with a date field, inserts / updates on components with date fields, and the existing collection flows that already worked all succeed against Postgres, MySQL, and SQLite. Unit tests cover the helper's coercion, idempotency, null / undefined pass-through, and no-touch behaviour for non-date fields.

nextly

Patch Changes

• #52 9bc10b6 Thanks @aqib-rx! - Fix update operation failed on table '<table>': value.toISOString is not a function when saving a Single document or a component instance that includes a date field. JSON request bodies deliver date values as ISO strings (e.g. "2026-05-20T12:22:29.417Z"), but Drizzle binds timestamp columns by calling .toISOString() on the bound value -- so an unmodified string travelling through the adapter blows up at the driver layer. CollectionMutationService already coerced date strings into Date objects inline at every write site, but the equivalent step was missing from SingleMutationService.update and from ComponentMutationService.serializeComponentRow (which feeds every insert / update path in the component service via buildInsertRow and direct calls).

  A new coerceDateFieldsToDate(data, fields) helper in shared/lib/field-transform.ts mutates the row in place, converting string values for field.type === "date" columns into Date objects. Existing Date, null, and undefined values pass through untouched, so the function is idempotent and safe to call on rows that were coerced upstream. The signature accepts a structural ReadonlyArray<{ name?: string; type?: string }> so the same helper covers both FieldConfig[] (singles, components) and the runtime FieldDefinition[] (collections). The helper is wired into single-mutation-service.update before snake-casing the row and into component-mutation-service.serializeComponentRow before column mapping. The six inline copies of the same coercion block in collection-mutation-service.ts were collapsed onto the shared helper as part of the same change so there is one implementation across all three domains. Result: PATCH /admin/api/singles/<slug> with a date field, inserts / updates on components with date fields, and the existing collection flows that already worked all succeed against Postgres, MySQL, and SQLite. Unit tests cover the helper's coercion, idempotency, null / undefined pass-through, and no-touch behaviour for non-date fields.

• Updated dependencies [9bc10b6]:

  • @nextlyhq/adapter-drizzle@0.0.2-alpha.16
  • @nextlyhq/adapter-mysql@0.0.2-alpha.16
  • @nextlyhq/adapter-postgres@0.0.2-alpha.16
  • @nextlyhq/adapter-sqlite@0.0.2-alpha.16

@nextlyhq/plugin-form-builder

Patch Changes

• #52 9bc10b6 Thanks @aqib-rx! - Fix update operation failed on table '<table>': value.toISOString is not a function when saving a Single document or a component instance that includes a date field. JSON request bodies deliver date values as ISO strings (e.g. "2026-05-20T12:22:29.417Z"), but Drizzle binds timestamp columns by calling .toISOString() on the bound value -- so an unmodified string travelling through the adapter blows up at the driver layer. CollectionMutationService already coerced date strings into Date objects inline at every write site, but the equivalent step was missing from SingleMutationService.update and from ComponentMutationService.serializeComponentRow (which feeds every insert / update path in the component service via buildInsertRow and direct calls).

  A new coerceDateFieldsToDate(data, fields) helper in shared/lib/field-transform.ts mutates the row in place, converting string values for field.type === "date" columns into Date objects. Existing Date, null, and undefined values pass through untouched, so the function is idempotent and safe to call on rows that were coerced upstream. The signature accepts a structural ReadonlyArray<{ name?: string; type?: string }> so the same helper covers both FieldConfig[] (singles, components) and the runtime FieldDefinition[] (collections). The helper is wired into single-mutation-service.update before snake-casing the row and into component-mutation-service.serializeComponentRow before column mapping. The six inline copies of the same coercion block in collection-mutation-service.ts were collapsed onto the shared helper as part of the same change so there is one implementation across all three domains. Result: PATCH /admin/api/singles/<slug> with a date field, inserts / updates on components with date fields, and the existing collection flows that already worked all succeed against Postgres, MySQL, and SQLite. Unit tests cover the helper's coercion, idempotency, null / undefined pass-through, and no-touch behaviour for non-date fields.

• Updated dependencies [9bc10b6]:

  • @nextlyhq/admin@0.0.2-alpha.16
  • nextly@0.0.2-alpha.16
  • @nextlyhq/ui@0.0.2-alpha.16

@nextlyhq/storage-s3

Patch Changes

• #52 9bc10b6 Thanks @aqib-rx! - Fix update operation failed on table '<table>': value.toISOString is not a function when saving a Single document or a component instance that includes a date field. JSON request bodies deliver date values as ISO strings (e.g. "2026-05-20T12:22:29.417Z"), but Drizzle binds timestamp columns by calling .toISOString() on the bound value -- so an unmodified string travelling through the adapter blows up at the driver layer. CollectionMutationService already coerced date strings into Date objects inline at every write site, but the equivalent step was missing from SingleMutationService.update and from ComponentMutationService.serializeComponentRow (which feeds every insert / update path in the component service via buildInsertRow and direct calls).

  A new coerceDateFieldsToDate(data, fields) helper in shared/lib/field-transform.ts mutates the row in place, converting string values for field.type === "date" columns into Date objects. Existing Date, null, and undefined values pass through untouched, so the function is idempotent and safe to call on rows that were coerced upstream. The signature accepts a structural ReadonlyArray<{ name?: string; type?: string }> so the same helper covers both FieldConfig[] (singles, components) and the runtime FieldDefinition[] (collections). The helper is wired into single-mutation-service.update before snake-casing the row and into component-mutation-service.serializeComponentRow before column mapping. The six inline copies of the same coercion block in collection-mutation-service.ts were collapsed onto the shared helper as part of the same change so there is one implementation across all three domains. Result: PATCH /admin/api/singles/<slug> with a date field, inserts / updates on components with date fields, and the existing collection flows that already worked all succeed against Postgres, MySQL, and SQLite. Unit tests cover the helper's coercion, idempotency, null / undefined pass-through, and no-touch behaviour for non-date fields.

@nextlyhq/storage-uploadthing

Patch Changes

• #52 9bc10b6 Thanks @aqib-rx! - Fix update operation failed on table '<table>': value.toISOString is not a function when saving a Single document or a component instance that includes a date field. JSON request bodies deliver date values as ISO strings (e.g. "2026-05-20T12:22:29.417Z"), but Drizzle binds timestamp columns by calling .toISOString() on the bound value -- so an unmodified string travelling through the adapter blows up at the driver layer. CollectionMutationService already coerced date strings into Date objects inline at every write site, but the equivalent step was missing from SingleMutationService.update and from ComponentMutationService.serializeComponentRow (which feeds every insert / update path in the component service via buildInsertRow and direct calls).

  A new coerceDateFieldsToDate(data, fields) helper in shared/lib/field-transform.ts mutates the row in place, converting string values for field.type === "date" columns into Date objects. Existing Date, null, and undefined values pass through untouched, so the function is idempotent and safe to call on rows that were coerced upstream. The signature accepts a structural ReadonlyArray<{ name?: string; type?: string }> so the same helper covers both FieldConfig[] (singles, components) and the runtime FieldDefinition[] (collections). The helper is wired into single-mutation-service.update before snake-casing the row and into component-mutation-service.serializeComponentRow before column mapping. The six inline copies of the same coercion block in collection-mutation-service.ts were collapsed onto the shared helper as part of the same change so there is one implementation across all three domains. Result: PATCH /admin/api/singles/<slug> with a date field, inserts / updates on components with date fields, and the existing collection flows that already worked all succeed against Postgres, MySQL, and SQLite. Unit tests cover the helper's coercion, idempotency, null / undefined pass-through, and no-touch behaviour for non-date fields.

@nextlyhq/storage-vercel-blob

Patch Changes

• #52 9bc10b6 Thanks @aqib-rx! - Fix update operation failed on table '<table>': value.toISOString is not a function when saving a Single document or a component instance that includes a date field. JSON request bodies deliver date values as ISO strings (e.g. "2026-05-20T12:22:29.417Z"), but Drizzle binds timestamp columns by calling .toISOString() on the bound value -- so an unmodified string travelling through the adapter blows up at the driver layer. CollectionMutationService already coerced date strings into Date objects inline at every write site, but the equivalent step was missing from SingleMutationService.update and from ComponentMutationService.serializeComponentRow (which feeds every insert / update path in the component service via buildInsertRow and direct calls).

  A new coerceDateFieldsToDate(data, fields) helper in shared/lib/field-transform.ts mutates the row in place, converting string values for field.type === "date" columns into Date objects. Existing Date, null, and undefined values pass through untouched, so the function is idempotent and safe to call on rows that were coerced upstream. The signature accepts a structural ReadonlyArray<{ name?: string; type?: string }> so the same helper covers both FieldConfig[] (singles, components) and the runtime FieldDefinition[] (collections). The helper is wired into single-mutation-service.update before snake-casing the row and into component-mutation-service.serializeComponentRow before column mapping. The six inline copies of the same coercion block in collection-mutation-service.ts were collapsed onto the shared helper as part of the same change so there is one implementation across all three domains. Result: PATCH /admin/api/singles/<slug> with a date field, inserts / updates on components with date fields, and the existing collection flows that already worked all succeed against Postgres, MySQL, and SQLite. Unit tests cover the helper's coercion, idempotency, null / undefined pass-through, and no-touch behaviour for non-date fields.

@nextlyhq/ui

Patch Changes

• #52 9bc10b6 Thanks @aqib-rx! - Fix update operation failed on table '<table>': value.toISOString is not a function when saving a Single document or a component instance that includes a date field. JSON request bodies deliver date values as ISO strings (e.g. "2026-05-20T12:22:29.417Z"), but Drizzle binds timestamp columns by calling .toISOString() on the bound value -- so an unmodified string travelling through the adapter blows up at the driver layer. CollectionMutationService already coerced date strings into Date objects inline at every write site, but the equivalent step was missing from SingleMutationService.update and from ComponentMutationService.serializeComponentRow (which feeds every insert / update path in the component service via buildInsertRow and direct calls).

  A new coerceDateFieldsToDate(data, fields) helper in shared/lib/field-transform.ts mutates the row in place, converting string values for field.type === "date" columns into Date objects. Existing Date, null, and undefined values pass through untouched, so the function is idempotent and safe to call on rows that were coerced upstream. The signature accepts a structural ReadonlyArray<{ name?: string; type?: string }> so the same helper covers both FieldConfig[] (singles, components) and the runtime FieldDefinition[] (collections). The helper is wired into single-mutation-service.update before snake-casing the row and into component-mutation-service.serializeComponentRow before column mapping. The six inline copies of the same coercion block in collection-mutation-service.ts were collapsed onto the shared helper as part of the same change so there is one implementation across all three domains. Result: PATCH /admin/api/singles/<slug> with a date field, inserts / updates on components with date fields, and the existing collection flows that already worked all succeed against Postgres, MySQL, and SQLite. Unit tests cover the helper's coercion, idempotency, null / undefined pass-through, and no-touch behaviour for non-date fields.