v0.0.2-alpha.45

Released 17 packages at 0.0.2-alpha.45 in lockstep. Every package below ships at this version.

What's changed

Patch Changes

• #389 0c79043 Thanks @mobeenabdullah! - Field group REST endpoints moved from /api/components to /api/field-groups, and the route re-exports from nextly/api/components and nextly/api/components-detail to nextly/api/field-groups and nextly/api/field-groups-detail. Apps that re-export these handlers must rename their route files and imports; the old paths are removed rather than aliased.

• #388 711e0c5 Thanks @mobeenabdullah! - Generated types now use the Field Group vocabulary: nextly generate:types emits <Slug>FieldGroup interfaces and a Config.fieldGroups map, and the Direct API exposes FieldGroupSlug and DataFromFieldGroupSlug in place of their Component equivalents. Re-run nextly generate:types after upgrading so the generated file and these types agree.

• #392 b51f4e8 Thanks @mobeenabdullah! - The admin panel now calls reusable field structures Field Groups. They live at /admin/builder/field-groups (previously /admin/builder/components), and the navigation, dashboard tile, builder and list screens use the new wording. Bookmarks to the old admin URLs will not resolve.

• #386 2eeef30 Thanks @mobeenabdullah! - Reusable field structures are now called Field Groups. defineComponent() becomes defineFieldGroup(), the component() field helper becomes fieldGroup(), the components config key becomes fieldGroups, and plugins contribute them via contributes.fieldGroups. The old names are removed rather than aliased, so configs must be updated on upgrade.

  Stored data is untouched: tables, columns and the JSON written for existing content keep their current names, so this release moves no data and needs no migration.

  Configs and plugins still using the old key now fail at startup with a message naming the new one, rather than starting up with those definitions silently unregistered.

• #390 768bdc7 Thanks @mobeenabdullah! - The Direct API namespace nextly.components.* is now nextly.fieldGroups.*, and the dashboard, plugin admin metadata, and plugin introspection responses report field groups under a fieldGroups key. Reading the old namespace now reports the rename instead of failing as an undefined property.

• #397 663306a Thanks @mobeenabdullah! - Internal modules and services for reusable field structures now use field-group naming. This renames three container keys reachable through the exported getService(): componentRegistryService, componentSchemaService and componentDataService become fieldGroupRegistryService, fieldGroupSchemaService and fieldGroupDataService. The old keys are not aliased, so a call using one no longer resolves. The field group schema service also drops generateSchemaCode(), an unused generator that was reachable through that same accessor. Stored data, table names, config keys and HTTP routes are unchanged.

• #385 d135685 Thanks @mobeenabdullah! - fix(nextly): make version snapshots complete and safe to restore

  Several version-capture gaps that could lose or corrupt content on restore are fixed:

  • Restoring an old version captured the content it applied but not the content it replaced, so content written while versioning was off (held in no version) was destroyed on restore. The current document is now snapshotted as a "Before restore" version inside the restore transaction, protected by the existing retention logic. This covers both collections and singles.
  • A single's component snapshots stored relationship and upload fields expanded into whole related rows instead of reference ids, so a versioned single with a component relationship could not be restored (the write failed) and could leak the related row's fields past redaction. Component snapshots now store references only.
  • For a localized, status-bearing single restored at a non-default locale, the pre-restore snapshot recorded the main row's status instead of that locale's, so undoing a restore could publish content that was never published. The snapshot now records the restored locale's own status.
  • A localized single's snapshot recorded only the fields a partial edit touched, dropping the write locale's other, still-persisted translations. The snapshot now carries the full set of the write locale's translations.
  • Publishing every locale of a localized entry emitted only a single, document-wide entry.published, so a subscriber watching one language never heard its translation go live. Each companion locale that actually transitions to published now emits its own locale-tagged entry.published. The publish is also judged against the row read under its transaction lock, so it records nothing when the entry was deleted concurrently.

• #391 962fd25 Thanks @mobeenabdullah! - Add a version comparison (diff) engine and endpoint.

  You can now compare any two saved versions of a collection entry or a single and get a typed, field-by-field diff: word-level text changes, added, removed, moved, and edited items in repeatable and component fields (matched by their stable id, so inserting one row no longer marks every row after it as changed), and added or removed relationship targets. The diff is computed on the server and is access-gated and field-redacted exactly like reading a version, so a field you cannot read never appears in a diff. It is reachable over the dispatcher and as a standalone nextly/api/versions-diff route for both collections and singles. The admin comparison UI follows in a later change.

Packages

• @nextlyhq/adapter-drizzle
• @nextlyhq/adapter-mysql
• @nextlyhq/adapter-postgres
• @nextlyhq/adapter-sqlite
• @nextlyhq/admin
• @nextlyhq/admin-css
• @nextlyhq/blocks-engine
• @nextlyhq/plugin-form-builder
• @nextlyhq/plugin-page-builder
• @nextlyhq/plugin-sdk
• @nextlyhq/plugin-seo
• @nextlyhq/storage-s3
• @nextlyhq/storage-uploadthing
• @nextlyhq/storage-vercel-blob
• @nextlyhq/ui
• create-nextly-app
• nextly