Version Packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@opensaas/stack-core@0.27.0

Minor Changes

• #635 18c39c8 Thanks @borisno2! - Add a label seam for the admin UI: getLabelFieldName(listConfig) resolves the field that represents a list's rows as a single label (ui.labelField → name → title → id), and getItemLabel(listConfig, item) reads that field off a row, falling back to id when it's missing. Both are exported from the root entry point.

  import { getLabelFieldName, getItemLabel } from '@opensaas/stack-core'
  
  Post: list({
    fields: { title: text() },
    ui: { labelField: 'title' },
  })
  
  getLabelFieldName(listConfig) // 'title'
  getItemLabel(listConfig, item) // item.title, or item.id if title is missing

• #636 a15e566 Thanks @borisno2! - Add a relationship-options read primitive: getRelationshipOptions(context, config, relatedListKey, { search?, take?, selectedIds? }) returns a bounded, projected { id, label }[] for relationship editors. It selects only id and the resolved label field (via getLabelFieldName), so no depth-5 auto-include ever runs; search filters via contains when the label field is text; results are ordered by the label field; and currently-selected selectedIds are always unioned into the result even when outside the search/take window. Operation-level query access on the related list still applies (denied → []).

  Also adds a relationshipOptions op on context.serverAction so hosts can resolve options from a client without a bespoke endpoint:

  await context.serverAction({
    listKey: 'Post',
    action: 'relationshipOptions',
    field: 'author',
    search: 'ada',
    take: 20,
    selectedIds: ['user-123'],
  })
  // => { success: true, data: [{ id: 'user-123', label: 'Ada Lovelace' }, ...] }

  getRelationshipOptions is exported from @opensaas/stack-core and re-exported from @opensaas/stack-ui for server components that already hold a context.

Patch Changes

• #633 9d9c7f8 Thanks @borisno2! - Fix virtual fields named in include/select throwing a Prisma "Unknown field" error. Virtual field keys are now stripped from the query payload while their value is still computed via resolveOutput.

• #637 002e755 Thanks @borisno2! - Fix calendarDay writes 500ing on Prisma 7 @db.Date columns — a resolveInput hook now coerces a YYYY-MM-DD string to a UTC-midnight Date before validation, and the field's zod schema accepts either shape.

@opensaas/stack-ui@0.27.0

Minor Changes

• #638 95560e4 Thanks @borisno2! - Wire the edit page onto the relationship-options primitive so relationship dropdowns are fast and live-searchable. The item-form preparation now fetches a bounded, take-limited window via getRelationshipOptions instead of an unbounded findMany({}) per relationship field, always unioning the current value's id(s) so its label renders even outside the window.

  ComboboxField (single) and RelationshipManager (many) gain debounced live search: typing narrows results against the label field via the relationshipOptions serverAction op, without any wiring changes required in host apps — ItemForm/SingletonView already pass serverAction and listKey through.

  // No config changes needed — AdminUI's edit page picks this up automatically.
  // A field's relationship dropdown now:
  // 1. Renders a bounded initial window (default 50) with the current value's label always visible
  // 2. Debounces typed input and searches server-side via context.serverAction({ action: 'relationshipOptions', ... })

  Components without a wired serverAction (e.g. custom usages of ComboboxField/RelationshipManager) fall back to client-side filtering over the initial window, unchanged from previous behavior.

• #636 a15e566 Thanks @borisno2! - Add a relationship-options read primitive: getRelationshipOptions(context, config, relatedListKey, { search?, take?, selectedIds? }) returns a bounded, projected { id, label }[] for relationship editors. It selects only id and the resolved label field (via getLabelFieldName), so no depth-5 auto-include ever runs; search filters via contains when the label field is text; results are ordered by the label field; and currently-selected selectedIds are always unioned into the result even when outside the search/take window. Operation-level query access on the related list still applies (denied → []).

  Also adds a relationshipOptions op on context.serverAction so hosts can resolve options from a client without a bespoke endpoint:

  await context.serverAction({
    listKey: 'Post',
    action: 'relationshipOptions',
    field: 'author',
    search: 'ada',
    take: 20,
    selectedIds: ['user-123'],
  })
  // => { success: true, data: [{ id: 'user-123', label: 'Ada Lovelace' }, ...] }

  getRelationshipOptions is exported from @opensaas/stack-core and re-exported from @opensaas/stack-ui for server components that already hold a context.

Patch Changes

• #639 3b2beb7 Thanks @borisno2! - List-page relationship cells now render their label via the shared label seam (getItemLabel), honouring a related list's ui.labelField instead of an inline name → title → label → id guess that had drifted from the item form.

@opensaas/stack-cli@0.27.0

Patch Changes

• Updated dependencies [18c39c8, 9d9c7f8, 002e755, a15e566]:
  • @opensaas/stack-core@0.27.0

@opensaas/stack-auth@0.27.0

@opensaas/stack-rag@0.27.0

@opensaas/stack-storage@0.27.0

@opensaas/stack-storage-s3@0.27.0

@opensaas/stack-storage-vercel@0.27.0

@opensaas/stack-tiptap@0.27.0

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
stack-docs	Ready	Preview, Comment	Jul 10, 2026 1:03pm