v0.0.2-alpha.18

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

What's changed

@nextlyhq/adapter-drizzle

Patch Changes

• #55 de3ec7e Thanks @faisal-rx! - Three related singles / API consistency fixes.

  REST responses for collections previously included both snake_case (created_at, updated_at) and camelCase (createdAt, updatedAt) variants of the system timestamp fields. The conversion helper added the camelCase aliases but never removed the snake_case originals, so list and detail endpoints surfaced duplicate keys per row. The snake-to-camel conversion now lives in a single helper, convertTimestampsToCamelCase, exported from shared/lib/case-conversion.ts next to the existing keysToCamelCase / keysToSnakeCase utilities. Both collection-query-service and the singles deserializeJsonFields path call it directly. The previous withTimestampAliases wrapper and its re-export from domains/collections/index.ts are removed. Collections responses now match singles / media / users / api-keys / uploads, which already emitted the camelCase form only.

  The admin sidebar's singles list now renders every single in the project rather than capping at the useSingles() default page size of 10. DynamicSingleNav drives a useInfiniteQuery against the singles endpoint and walks subsequent pages while meta.hasNext is true. Each request is bounded to 100 rows so per-request DB load stays small. Secondary consumers that derive visibility or grouping data from the singles list (DualSidebar, DynamicCustomGroupNav, SinglesLandingRedirect) now pass an explicit pageSize: 100 to useSingles, matching the pattern already used by the collections sidebar fetch. This stops the same truncation symptom from hiding section headers or misrouting the /admin/singles landing redirect when the project has more than 10 singles.

  The GET /admin/api/singles handler now accepts a 1-based page query parameter as an alternative to offset. The admin UI's shared buildQuery helper emits page for every paginated route; previously the singles endpoint read only offset, so a page change in the Singles builder table left the offset at 0 and the same first page was returned for every navigation. When both offset and page are supplied offset wins, preserving the existing external API contract.

@nextlyhq/adapter-mysql

Patch Changes

• #55 de3ec7e Thanks @faisal-rx! - Three related singles / API consistency fixes.

  REST responses for collections previously included both snake_case (created_at, updated_at) and camelCase (createdAt, updatedAt) variants of the system timestamp fields. The conversion helper added the camelCase aliases but never removed the snake_case originals, so list and detail endpoints surfaced duplicate keys per row. The snake-to-camel conversion now lives in a single helper, convertTimestampsToCamelCase, exported from shared/lib/case-conversion.ts next to the existing keysToCamelCase / keysToSnakeCase utilities. Both collection-query-service and the singles deserializeJsonFields path call it directly. The previous withTimestampAliases wrapper and its re-export from domains/collections/index.ts are removed. Collections responses now match singles / media / users / api-keys / uploads, which already emitted the camelCase form only.

  The admin sidebar's singles list now renders every single in the project rather than capping at the useSingles() default page size of 10. DynamicSingleNav drives a useInfiniteQuery against the singles endpoint and walks subsequent pages while meta.hasNext is true. Each request is bounded to 100 rows so per-request DB load stays small. Secondary consumers that derive visibility or grouping data from the singles list (DualSidebar, DynamicCustomGroupNav, SinglesLandingRedirect) now pass an explicit pageSize: 100 to useSingles, matching the pattern already used by the collections sidebar fetch. This stops the same truncation symptom from hiding section headers or misrouting the /admin/singles landing redirect when the project has more than 10 singles.

  The GET /admin/api/singles handler now accepts a 1-based page query parameter as an alternative to offset. The admin UI's shared buildQuery helper emits page for every paginated route; previously the singles endpoint read only offset, so a page change in the Singles builder table left the offset at 0 and the same first page was returned for every navigation. When both offset and page are supplied offset wins, preserving the existing external API contract.

• Updated dependencies [de3ec7e]:

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

@nextlyhq/adapter-postgres

Patch Changes

• #55 de3ec7e Thanks @faisal-rx! - Three related singles / API consistency fixes.

  REST responses for collections previously included both snake_case (created_at, updated_at) and camelCase (createdAt, updatedAt) variants of the system timestamp fields. The conversion helper added the camelCase aliases but never removed the snake_case originals, so list and detail endpoints surfaced duplicate keys per row. The snake-to-camel conversion now lives in a single helper, convertTimestampsToCamelCase, exported from shared/lib/case-conversion.ts next to the existing keysToCamelCase / keysToSnakeCase utilities. Both collection-query-service and the singles deserializeJsonFields path call it directly. The previous withTimestampAliases wrapper and its re-export from domains/collections/index.ts are removed. Collections responses now match singles / media / users / api-keys / uploads, which already emitted the camelCase form only.

  The admin sidebar's singles list now renders every single in the project rather than capping at the useSingles() default page size of 10. DynamicSingleNav drives a useInfiniteQuery against the singles endpoint and walks subsequent pages while meta.hasNext is true. Each request is bounded to 100 rows so per-request DB load stays small. Secondary consumers that derive visibility or grouping data from the singles list (DualSidebar, DynamicCustomGroupNav, SinglesLandingRedirect) now pass an explicit pageSize: 100 to useSingles, matching the pattern already used by the collections sidebar fetch. This stops the same truncation symptom from hiding section headers or misrouting the /admin/singles landing redirect when the project has more than 10 singles.

  The GET /admin/api/singles handler now accepts a 1-based page query parameter as an alternative to offset. The admin UI's shared buildQuery helper emits page for every paginated route; previously the singles endpoint read only offset, so a page change in the Singles builder table left the offset at 0 and the same first page was returned for every navigation. When both offset and page are supplied offset wins, preserving the existing external API contract.

• Updated dependencies [de3ec7e]:

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

@nextlyhq/adapter-sqlite

Patch Changes

• #55 de3ec7e Thanks @faisal-rx! - Three related singles / API consistency fixes.

  REST responses for collections previously included both snake_case (created_at, updated_at) and camelCase (createdAt, updatedAt) variants of the system timestamp fields. The conversion helper added the camelCase aliases but never removed the snake_case originals, so list and detail endpoints surfaced duplicate keys per row. The snake-to-camel conversion now lives in a single helper, convertTimestampsToCamelCase, exported from shared/lib/case-conversion.ts next to the existing keysToCamelCase / keysToSnakeCase utilities. Both collection-query-service and the singles deserializeJsonFields path call it directly. The previous withTimestampAliases wrapper and its re-export from domains/collections/index.ts are removed. Collections responses now match singles / media / users / api-keys / uploads, which already emitted the camelCase form only.

  The admin sidebar's singles list now renders every single in the project rather than capping at the useSingles() default page size of 10. DynamicSingleNav drives a useInfiniteQuery against the singles endpoint and walks subsequent pages while meta.hasNext is true. Each request is bounded to 100 rows so per-request DB load stays small. Secondary consumers that derive visibility or grouping data from the singles list (DualSidebar, DynamicCustomGroupNav, SinglesLandingRedirect) now pass an explicit pageSize: 100 to useSingles, matching the pattern already used by the collections sidebar fetch. This stops the same truncation symptom from hiding section headers or misrouting the /admin/singles landing redirect when the project has more than 10 singles.

  The GET /admin/api/singles handler now accepts a 1-based page query parameter as an alternative to offset. The admin UI's shared buildQuery helper emits page for every paginated route; previously the singles endpoint read only offset, so a page change in the Singles builder table left the offset at 0 and the same first page was returned for every navigation. When both offset and page are supplied offset wins, preserving the existing external API contract.

• Updated dependencies [de3ec7e]:

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

@nextlyhq/admin

Patch Changes

• #55 de3ec7e Thanks @faisal-rx! - Three related singles / API consistency fixes.

  REST responses for collections previously included both snake_case (created_at, updated_at) and camelCase (createdAt, updatedAt) variants of the system timestamp fields. The conversion helper added the camelCase aliases but never removed the snake_case originals, so list and detail endpoints surfaced duplicate keys per row. The snake-to-camel conversion now lives in a single helper, convertTimestampsToCamelCase, exported from shared/lib/case-conversion.ts next to the existing keysToCamelCase / keysToSnakeCase utilities. Both collection-query-service and the singles deserializeJsonFields path call it directly. The previous withTimestampAliases wrapper and its re-export from domains/collections/index.ts are removed. Collections responses now match singles / media / users / api-keys / uploads, which already emitted the camelCase form only.

  The admin sidebar's singles list now renders every single in the project rather than capping at the useSingles() default page size of 10. DynamicSingleNav drives a useInfiniteQuery against the singles endpoint and walks subsequent pages while meta.hasNext is true. Each request is bounded to 100 rows so per-request DB load stays small. Secondary consumers that derive visibility or grouping data from the singles list (DualSidebar, DynamicCustomGroupNav, SinglesLandingRedirect) now pass an explicit pageSize: 100 to useSingles, matching the pattern already used by the collections sidebar fetch. This stops the same truncation symptom from hiding section headers or misrouting the /admin/singles landing redirect when the project has more than 10 singles.

  The GET /admin/api/singles handler now accepts a 1-based page query parameter as an alternative to offset. The admin UI's shared buildQuery helper emits page for every paginated route; previously the singles endpoint read only offset, so a page change in the Singles builder table left the offset at 0 and the same first page was returned for every navigation. When both offset and page are supplied offset wins, preserving the existing external API contract.

• Updated dependencies [de3ec7e]:

  • @nextlyhq/ui@0.0.2-alpha.18

create-nextly-app

Patch Changes

• #55 de3ec7e Thanks @faisal-rx! - Three related singles / API consistency fixes.

  REST responses for collections previously included both snake_case (created_at, updated_at) and camelCase (createdAt, updatedAt) variants of the system timestamp fields. The conversion helper added the camelCase aliases but never removed the snake_case originals, so list and detail endpoints surfaced duplicate keys per row. The snake-to-camel conversion now lives in a single helper, convertTimestampsToCamelCase, exported from shared/lib/case-conversion.ts next to the existing keysToCamelCase / keysToSnakeCase utilities. Both collection-query-service and the singles deserializeJsonFields path call it directly. The previous withTimestampAliases wrapper and its re-export from domains/collections/index.ts are removed. Collections responses now match singles / media / users / api-keys / uploads, which already emitted the camelCase form only.

  The admin sidebar's singles list now renders every single in the project rather than capping at the useSingles() default page size of 10. DynamicSingleNav drives a useInfiniteQuery against the singles endpoint and walks subsequent pages while meta.hasNext is true. Each request is bounded to 100 rows so per-request DB load stays small. Secondary consumers that derive visibility or grouping data from the singles list (DualSidebar, DynamicCustomGroupNav, SinglesLandingRedirect) now pass an explicit pageSize: 100 to useSingles, matching the pattern already used by the collections sidebar fetch. This stops the same truncation symptom from hiding section headers or misrouting the /admin/singles landing redirect when the project has more than 10 singles.

  The GET /admin/api/singles handler now accepts a 1-based page query parameter as an alternative to offset. The admin UI's shared buildQuery helper emits page for every paginated route; previously the singles endpoint read only offset, so a page change in the Singles builder table left the offset at 0 and the same first page was returned for every navigation. When both offset and page are supplied offset wins, preserving the existing external API contract.

nextly

Patch Changes

• #55 de3ec7e Thanks @faisal-rx! - Three related singles / API consistency fixes.

  REST responses for collections previously included both snake_case (created_at, updated_at) and camelCase (createdAt, updatedAt) variants of the system timestamp fields. The conversion helper added the camelCase aliases but never removed the snake_case originals, so list and detail endpoints surfaced duplicate keys per row. The snake-to-camel conversion now lives in a single helper, convertTimestampsToCamelCase, exported from shared/lib/case-conversion.ts next to the existing keysToCamelCase / keysToSnakeCase utilities. Both collection-query-service and the singles deserializeJsonFields path call it directly. The previous withTimestampAliases wrapper and its re-export from domains/collections/index.ts are removed. Collections responses now match singles / media / users / api-keys / uploads, which already emitted the camelCase form only.

  The admin sidebar's singles list now renders every single in the project rather than capping at the useSingles() default page size of 10. DynamicSingleNav drives a useInfiniteQuery against the singles endpoint and walks subsequent pages while meta.hasNext is true. Each request is bounded to 100 rows so per-request DB load stays small. Secondary consumers that derive visibility or grouping data from the singles list (DualSidebar, DynamicCustomGroupNav, SinglesLandingRedirect) now pass an explicit pageSize: 100 to useSingles, matching the pattern already used by the collections sidebar fetch. This stops the same truncation symptom from hiding section headers or misrouting the /admin/singles landing redirect when the project has more than 10 singles.

  The GET /admin/api/singles handler now accepts a 1-based page query parameter as an alternative to offset. The admin UI's shared buildQuery helper emits page for every paginated route; previously the singles endpoint read only offset, so a page change in the Singles builder table left the offset at 0 and the same first page was returned for every navigation. When both offset and page are supplied offset wins, preserving the existing external API contract.

• Updated dependencies [de3ec7e]:

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

@nextlyhq/plugin-form-builder

Patch Changes

• #55 de3ec7e Thanks @faisal-rx! - Three related singles / API consistency fixes.

  REST responses for collections previously included both snake_case (created_at, updated_at) and camelCase (createdAt, updatedAt) variants of the system timestamp fields. The conversion helper added the camelCase aliases but never removed the snake_case originals, so list and detail endpoints surfaced duplicate keys per row. The snake-to-camel conversion now lives in a single helper, convertTimestampsToCamelCase, exported from shared/lib/case-conversion.ts next to the existing keysToCamelCase / keysToSnakeCase utilities. Both collection-query-service and the singles deserializeJsonFields path call it directly. The previous withTimestampAliases wrapper and its re-export from domains/collections/index.ts are removed. Collections responses now match singles / media / users / api-keys / uploads, which already emitted the camelCase form only.

  The admin sidebar's singles list now renders every single in the project rather than capping at the useSingles() default page size of 10. DynamicSingleNav drives a useInfiniteQuery against the singles endpoint and walks subsequent pages while meta.hasNext is true. Each request is bounded to 100 rows so per-request DB load stays small. Secondary consumers that derive visibility or grouping data from the singles list (DualSidebar, DynamicCustomGroupNav, SinglesLandingRedirect) now pass an explicit pageSize: 100 to useSingles, matching the pattern already used by the collections sidebar fetch. This stops the same truncation symptom from hiding section headers or misrouting the /admin/singles landing redirect when the project has more than 10 singles.

  The GET /admin/api/singles handler now accepts a 1-based page query parameter as an alternative to offset. The admin UI's shared buildQuery helper emits page for every paginated route; previously the singles endpoint read only offset, so a page change in the Singles builder table left the offset at 0 and the same first page was returned for every navigation. When both offset and page are supplied offset wins, preserving the existing external API contract.

• Updated dependencies [de3ec7e]:

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

@nextlyhq/storage-s3

Patch Changes

• #55 de3ec7e Thanks @faisal-rx! - Three related singles / API consistency fixes.

  REST responses for collections previously included both snake_case (created_at, updated_at) and camelCase (createdAt, updatedAt) variants of the system timestamp fields. The conversion helper added the camelCase aliases but never removed the snake_case originals, so list and detail endpoints surfaced duplicate keys per row. The snake-to-camel conversion now lives in a single helper, convertTimestampsToCamelCase, exported from shared/lib/case-conversion.ts next to the existing keysToCamelCase / keysToSnakeCase utilities. Both collection-query-service and the singles deserializeJsonFields path call it directly. The previous withTimestampAliases wrapper and its re-export from domains/collections/index.ts are removed. Collections responses now match singles / media / users / api-keys / uploads, which already emitted the camelCase form only.

  The admin sidebar's singles list now renders every single in the project rather than capping at the useSingles() default page size of 10. DynamicSingleNav drives a useInfiniteQuery against the singles endpoint and walks subsequent pages while meta.hasNext is true. Each request is bounded to 100 rows so per-request DB load stays small. Secondary consumers that derive visibility or grouping data from the singles list (DualSidebar, DynamicCustomGroupNav, SinglesLandingRedirect) now pass an explicit pageSize: 100 to useSingles, matching the pattern already used by the collections sidebar fetch. This stops the same truncation symptom from hiding section headers or misrouting the /admin/singles landing redirect when the project has more than 10 singles.

  The GET /admin/api/singles handler now accepts a 1-based page query parameter as an alternative to offset. The admin UI's shared buildQuery helper emits page for every paginated route; previously the singles endpoint read only offset, so a page change in the Singles builder table left the offset at 0 and the same first page was returned for every navigation. When both offset and page are supplied offset wins, preserving the existing external API contract.

@nextlyhq/storage-uploadthing

Patch Changes

• #55 de3ec7e Thanks @faisal-rx! - Three related singles / API consistency fixes.

  REST responses for collections previously included both snake_case (created_at, updated_at) and camelCase (createdAt, updatedAt) variants of the system timestamp fields. The conversion helper added the camelCase aliases but never removed the snake_case originals, so list and detail endpoints surfaced duplicate keys per row. The snake-to-camel conversion now lives in a single helper, convertTimestampsToCamelCase, exported from shared/lib/case-conversion.ts next to the existing keysToCamelCase / keysToSnakeCase utilities. Both collection-query-service and the singles deserializeJsonFields path call it directly. The previous withTimestampAliases wrapper and its re-export from domains/collections/index.ts are removed. Collections responses now match singles / media / users / api-keys / uploads, which already emitted the camelCase form only.

  The admin sidebar's singles list now renders every single in the project rather than capping at the useSingles() default page size of 10. DynamicSingleNav drives a useInfiniteQuery against the singles endpoint and walks subsequent pages while meta.hasNext is true. Each request is bounded to 100 rows so per-request DB load stays small. Secondary consumers that derive visibility or grouping data from the singles list (DualSidebar, DynamicCustomGroupNav, SinglesLandingRedirect) now pass an explicit pageSize: 100 to useSingles, matching the pattern already used by the collections sidebar fetch. This stops the same truncation symptom from hiding section headers or misrouting the /admin/singles landing redirect when the project has more than 10 singles.

  The GET /admin/api/singles handler now accepts a 1-based page query parameter as an alternative to offset. The admin UI's shared buildQuery helper emits page for every paginated route; previously the singles endpoint read only offset, so a page change in the Singles builder table left the offset at 0 and the same first page was returned for every navigation. When both offset and page are supplied offset wins, preserving the existing external API contract.

@nextlyhq/storage-vercel-blob

Patch Changes

• #55 de3ec7e Thanks @faisal-rx! - Three related singles / API consistency fixes.

  REST responses for collections previously included both snake_case (created_at, updated_at) and camelCase (createdAt, updatedAt) variants of the system timestamp fields. The conversion helper added the camelCase aliases but never removed the snake_case originals, so list and detail endpoints surfaced duplicate keys per row. The snake-to-camel conversion now lives in a single helper, convertTimestampsToCamelCase, exported from shared/lib/case-conversion.ts next to the existing keysToCamelCase / keysToSnakeCase utilities. Both collection-query-service and the singles deserializeJsonFields path call it directly. The previous withTimestampAliases wrapper and its re-export from domains/collections/index.ts are removed. Collections responses now match singles / media / users / api-keys / uploads, which already emitted the camelCase form only.

  The admin sidebar's singles list now renders every single in the project rather than capping at the useSingles() default page size of 10. DynamicSingleNav drives a useInfiniteQuery against the singles endpoint and walks subsequent pages while meta.hasNext is true. Each request is bounded to 100 rows so per-request DB load stays small. Secondary consumers that derive visibility or grouping data from the singles list (DualSidebar, DynamicCustomGroupNav, SinglesLandingRedirect) now pass an explicit pageSize: 100 to useSingles, matching the pattern already used by the collections sidebar fetch. This stops the same truncation symptom from hiding section headers or misrouting the /admin/singles landing redirect when the project has more than 10 singles.

  The GET /admin/api/singles handler now accepts a 1-based page query parameter as an alternative to offset. The admin UI's shared buildQuery helper emits page for every paginated route; previously the singles endpoint read only offset, so a page change in the Singles builder table left the offset at 0 and the same first page was returned for every navigation. When both offset and page are supplied offset wins, preserving the existing external API contract.

@nextlyhq/ui

Patch Changes

• #55 de3ec7e Thanks @faisal-rx! - Three related singles / API consistency fixes.

  REST responses for collections previously included both snake_case (created_at, updated_at) and camelCase (createdAt, updatedAt) variants of the system timestamp fields. The conversion helper added the camelCase aliases but never removed the snake_case originals, so list and detail endpoints surfaced duplicate keys per row. The snake-to-camel conversion now lives in a single helper, convertTimestampsToCamelCase, exported from shared/lib/case-conversion.ts next to the existing keysToCamelCase / keysToSnakeCase utilities. Both collection-query-service and the singles deserializeJsonFields path call it directly. The previous withTimestampAliases wrapper and its re-export from domains/collections/index.ts are removed. Collections responses now match singles / media / users / api-keys / uploads, which already emitted the camelCase form only.

  The admin sidebar's singles list now renders every single in the project rather than capping at the useSingles() default page size of 10. DynamicSingleNav drives a useInfiniteQuery against the singles endpoint and walks subsequent pages while meta.hasNext is true. Each request is bounded to 100 rows so per-request DB load stays small. Secondary consumers that derive visibility or grouping data from the singles list (DualSidebar, DynamicCustomGroupNav, SinglesLandingRedirect) now pass an explicit pageSize: 100 to useSingles, matching the pattern already used by the collections sidebar fetch. This stops the same truncation symptom from hiding section headers or misrouting the /admin/singles landing redirect when the project has more than 10 singles.

  The GET /admin/api/singles handler now accepts a 1-based page query parameter as an alternative to offset. The admin UI's shared buildQuery helper emits page for every paginated route; previously the singles endpoint read only offset, so a page change in the Singles builder table left the offset at 0 and the same first page was returned for every navigation. When both offset and page are supplied offset wins, preserving the existing external API contract.