Split out from #2545 Phase 3 (objectui side). These two are deliberately not bundled into a mechanical PR because the first is a design decision with real trade-offs; filing for a maintainer call before any code lands.
1. /ui zod-schema re-exports are value-erased (design decision)
packages/types/src/index.ts re-exports the entire @objectstack/spec/ui surface with export type { … } blocks — but those blocks include …Schema names, which are zod values, not types. Under export type, the values are erased, so:
import { DndConfigSchema } from '@object-ui/types';
DndConfigSchema; // => undefined at runtimeAny consumer importing a …Schema value from @object-ui/types silently gets undefined. (The one genuine value re-export block, index.ts:948-956 — defineStack etc. — is unaffected.)
Two ways to resolve, pick one:
- (a) Keep them type-only, drop the schema-name re-exports. If nothing is meant to consume these zod schemas as runtime values through
@object-ui/types, the …Schema names simply shouldn't be in the export type lists. Lowest blast radius, no new runtime coupling. Likely the intended design.
- (b) Convert to value re-exports (
export { … }). Makes the schemas actually usable at runtime, but gives @object-ui/types a real runtime dependency on @objectstack/spec for those exports — bundle-size / eager-load impact for every @object-ui/types consumer. Only worth it if there's a real need to hand these zod validators to consumers via the types package.
Recommendation: (a) unless someone can name a consumer that needs the runtime schema values — but this is a maintainer call, which is why it's an issue rather than a PR.
Suggested guardrail once decided: a tiny test asserting the chosen contract (either "these names are not runtime-exported" for (a), or "these schema values are defined, not undefined" for (b)) so it can't silently regress.
2. Bump @objectstack/spec pin ^14.6 → ^15
Low-risk on the type surface — the @objectstack/spec/ui export-name set is identical between 14.6.0 and 15.0.0. The only major in v15 is ADR-0089 D3a: FormFieldSchema / FormSectionSchema / PageComponentSchema became .strict() (unknown keys → parse error). So the bump itself is safe, but it should ride with validating example/test metadata under v15 strict mode to catch any fixture carrying an undeclared field/section-level key.
Touches: the 14 package.json files declaring @objectstack/spec + pnpm-lock.yaml regen.
Best sequenced after decision (1) so the re-export changes and the pin bump land as one coherent types-package PR.
Refs #2545, objectstack-ai/framework#2998.
Split out from #2545 Phase 3 (objectui side). These two are deliberately not bundled into a mechanical PR because the first is a design decision with real trade-offs; filing for a maintainer call before any code lands.
1.
/uizod-schema re-exports are value-erased (design decision)packages/types/src/index.tsre-exports the entire@objectstack/spec/uisurface withexport type { … }blocks — but those blocks include…Schemanames, which are zod values, not types. Underexport type, the values are erased, so:Any consumer importing a
…Schemavalue from@object-ui/typessilently getsundefined. (The one genuine value re-export block,index.ts:948-956—defineStacketc. — is unaffected.)Two ways to resolve, pick one:
@object-ui/types, the…Schemanames simply shouldn't be in theexport typelists. Lowest blast radius, no new runtime coupling. Likely the intended design.export { … }). Makes the schemas actually usable at runtime, but gives@object-ui/typesa real runtime dependency on@objectstack/specfor those exports — bundle-size / eager-load impact for every@object-ui/typesconsumer. Only worth it if there's a real need to hand these zod validators to consumers via the types package.Recommendation: (a) unless someone can name a consumer that needs the runtime schema values — but this is a maintainer call, which is why it's an issue rather than a PR.
Suggested guardrail once decided: a tiny test asserting the chosen contract (either "these names are not runtime-exported" for (a), or "these schema values are defined, not
undefined" for (b)) so it can't silently regress.2. Bump
@objectstack/specpin^14.6→^15Low-risk on the type surface — the
@objectstack/spec/uiexport-name set is identical between 14.6.0 and 15.0.0. The only major in v15 is ADR-0089 D3a:FormFieldSchema/FormSectionSchema/PageComponentSchemabecame.strict()(unknown keys → parse error). So the bump itself is safe, but it should ride with validating example/test metadata under v15 strict mode to catch any fixture carrying an undeclared field/section-level key.Touches: the 14
package.jsonfiles declaring@objectstack/spec+pnpm-lock.yamlregen.Best sequenced after decision (1) so the re-export changes and the pin bump land as one coherent types-package PR.
Refs #2545, objectstack-ai/framework#2998.