build(types): type-check this package's tests, so the spec-derivation guards actually run (objectstack#4074) - #3009
Merged
Merged
Conversation
…guards actually run (objectstack#4074) `spec-derived-unions.test.ts` exists to stop a spec-derived union from being re-forked into a hand-written copy, and its header claimed the `satisfies` checks in it "are the real enforcement". They were not. `tsconfig.json` excludes test files — correctly, since it is the package build with `rootDir` / `composite` / `declaration`, so tests would emit into dist — and no other `tsc` invocation read them. Measured, not assumed: reverting `ActionParamFieldType` from the spec's `FieldType` back to a hand-written subset produced ZERO type errors before this change, and now produces TS1360 on the `satisfies` line. The sibling guards over `ChartType`, `ReportType`, `ActionType` and `PageType` were equally inert, so the anti-regression mechanism left by #2944/#2901 was not running in CI. `tsconfig.test.json` follows the shape this package already uses for `tsconfig.examples.json`: a separate, emit-free project chained from `type-check`. Kept separate rather than deleting the exclude so the BUILD stays honest — the reexport guard's source scan needs `types: ["node"]`, and folding that into `tsconfig.json` would let package SOURCE reference Node APIs and still compile, in a package that ships to browsers. Turning it on surfaced 39 pre-existing errors in test files. Fixed: - `p2-spec-exports.test.ts` imported eight `…Schema` names as types from `../index`. #2561 decision (a) removed those and the sibling `spec-ui-schema-reexports.test.ts` asserts their absence, so this file contradicted its own guard for the whole interval — a type-only import of a nonexistent name erases at runtime, so the suite stayed green. Its minimal fixtures were also typed as parsed OUTPUT while being parse INPUT (these schemas `.default()` several fields); they use `z.input<>` now, the distinction spec draws itself with `ActionInput`. `operator: 'eq'` is a legacy alias spec folds at parse time — valid input, absent from the canonical output union. The value-type re-exports the file exists to pin are now asserted explicitly instead of implicitly through fixture annotations. - `app-creation-types.test.ts` / `system-fields.test.ts` imported the package by its own name; turbo's `type-check` dependsOn `^build` (upstream only), so the package's own dist does not exist when it runs. They use the relative import every sibling test uses. Declared as debt rather than fixed: `p1-spec-alignment.test.ts` is excluded with a written reason. Its 14 errors are not hygiene — every one sits in a test named "should accept <shape>" whose whole purpose is asserting the type accepts that shape, and the type rejects it. The clearest case, sharing as `{ visibility, enabled }`, describes a shape that IS handled by `foldSharing` in core's `normalize-list-view.ts`, but only as untyped input (`normalizeListViewSchema<T>(schema: T): T`), so no type names it. Each site is a separate decision — widen the type so the claim becomes true, or drop the claim — and several touch the public surface, so rewriting them silently here would bury the finding. Scope is deliberately narrow: only `packages/types` is converted. 28 other packages still exclude their tests, and 5 (`fields`, `cli`, `data-objectstack`, `plugin-charts`, `plugin-editor`) already include them. This establishes the pattern rather than sweeping the repo. Refs objectstack#4074, #3003, #2561, #2944, #2901, #2911 Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014DBMo8gnFduzgpuSHd5Eje
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
os-zhuang
marked this pull request as ready for review
July 30, 2026 10:18
os-zhuang
added a commit
that referenced
this pull request
Jul 30, 2026
… the spec's declaration forms, ListViewSchema stops promising phantom defaults (objectstack#4074) (#3020) Three public types said something different from what the platform accepts, found by making packages/types' tests compile (#3009) and resolving the declared p1-spec-alignment.test.ts debt site-by-site. ActionParam is now the AUTHORING shape, aligned with the spec's input: name/label/type optional, field/objectOverride added. The spec's primary declaration form — a bare field reference inheriting label/type/validation/ options from an object field — was unrepresentable while all three were required. The RESOLVED shape the dialog consumes (after app-shell's resolveActionParams() inlines the reference) remains core's ActionParamDef, all three required: authoring and resolved are different types on purpose. label is the spec's I18nLabel by import — which the new compile-time guard promptly revealed to be aliased to plain string in the current spec, so no behavioural widening today; importing the alias means objectui tracks any future widening automatically. ListViewInferred is z.input, not z.infer. The spec sub-schemas flowing into the list-view surface (userActions, tabs→ViewTab, sharing) carry .default()s, so the inferred output type made userActions.refresh or a tab's pinned/visible REQUIRED — but nothing on the render path runs .parse(): normalizeListViewSchema deliberately applies no defaults ("an absent flag stays absent", its own suite). The output type rejected valid authored metadata while promising renderers defaults that never arrive; input matches both author and runtime. FormField.dependsOn is DependsOnInput. The runtime reader (resolveCascadingOptions) has always accepted a bare name, a list of names, or {field, param} entries; the public property said string, so array-authored metadata type-errored while working and the form renderer read the key through (f as any).dependsOn to get past its own type. The shape now lives in @object-ui/types next to FormField; core imports and re-exports it; the two as-any reads in components are typed. The p1-spec-alignment.test.ts exclusion is gone — its 14 errors resolved: the "sharing in ObjectUI format" and legacy-ARIA fixtures are re-seated as normalizer-input dialects (folded by normalizeListViewSchema; asserted branch-by-branch in core's normalize-list-view.test.ts, the seam where the fold runs), and the one fixture no surface ever admitted (an ObjectQL triplet as a spec ViewTab.filter) is corrected to the rule-object form. Every test file in @object-ui/types is compiled, no exclusions. Discrimination-checked: reverting ListViewInferred to z.infer, dependsOn to string, or ActionParam.name to required each fails compile in the now-compiled tests (TS2739 / TS2322 / TS2741); restored, all projects clean. Claude-Session: https://claude.ai/code/session_014DBMo8gnFduzgpuSHd5Eje Co-authored-by: Claude <noreply@anthropic.com>
3 tasks
os-zhuang
added a commit
that referenced
this pull request
Jul 31, 2026
…engine stops disagreeing with the server (#3103) (#3107) Five rule types in `data-protocol.ts` were hand-written interfaces labelled `(ObjectStack Spec v2.0.1)` while the installed spec was 17.0.0-rc.0. Nothing bound them to the spec, so fifteen majors of drift accumulated with `tsc` silent and the comment still vouching for it — the planted-premise failure class objectstack#4115 was filed for. They are now `z.input` derivations of the spec's schemas. `z.input`, not `z.infer`: objectui consumes AUTHORED metadata off `/meta`, before the spec's defaults and ExpressionInput canonicalization run, so `condition` really is `string | {dialect, source}` and `active`/`events`/`priority` really can be absent. What the copies had drifted into, and what each cost the user — the engine is a client PRE-CHECK of rules `objectql/src/validation/rule-validator.ts` enforces, so every one of these is a disagreement with the authority: - Predicate POLARITY was inverted. The server violates a rule when the predicate is TRUE; the engine violated it when FALSE. Every spec-authored `script`/`cross_field` rule got the opposite verdict. - `conditional` read `condition` + `rules[]` where the spec says `when` + `then`/`otherwise` → silent no-op, and `otherwise` never ran at all. - `format` read `pattern` where the spec says `regex` → `undefined.test()` threw into a catch that reported a VIOLATION, blocking writes the server accepts. - Envelope-valued conditions hit `expression.trim()`, threw, and read as "passes" → silent no-op. - An absent `active` disabled the rule; an absent `events` threw. Both arrive absent because the spec defaults them at parse time. - `initialStates` (objectstack#3165) and `priority` were missing entirely; `events: 'delete'` was still advertised after objectstack#3184 retired it. `unique`/`async`/`range` have no spec counterpart — the spec removed the first two deliberately (uniqueness → a unique index, since SELECT-then-INSERT is racy; async → the form layer) — and are now @deprecated, with a test proving the spec's union rejects them, so the comment is load-bearing rather than decorative. Gates, each mutation-tested: the compile-time pins in `validation-rule-spec-parity.test.ts` (live because tsconfig.test.json compiles it, #3009) go TS1360 when a derivation is reverted, and the engine suite goes red for polarity, envelope coercion, `otherwise`, `initialStates` and the spec defaults. `ConditionalValidation.then/otherwise` carry one pinned divergence — the spec's published types erase them to `unknown` (objectstack#4171) — with an inverted pin that fails the day upstream fixes it. Canonicity now rides on the import and the gate, not the comment: `grep "Spec v2.0.1" packages/types/src/data-protocol.ts` is empty, and objectstack#4115's ledger drops 120 -> 115. Co-authored-by: Jack Zhuang <277994282+os-zhuang@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #3003. While correcting a comment there I measured something worth its own change:
spec-derived-unions.test.ts— the file that exists to stop a spec-derived union from being re-forked into a hand-written copy — was not being compiled by anything.Measured, not assumed
Its header claimed the
satisfieschecks in it "are the real enforcement". RevertingActionParamFieldTypefrom the spec'sFieldTypeback to a hand-written subset:tscoutputTS1360on thesatisfieslinetsconfig.jsonexcludes test files — correctly, since it is the package build (rootDir/composite/declaration), so tests would emit intodist— and no othertscinvocation read them. There is no vitesttypecheckproject either.The sibling guards over
ChartType,ReportType,ActionTypeandPageTypewere inert for the same reason, so the anti-regression mechanism left behind by #2944 / #2901 was not running in CI. Those forks were each already drifted once when they were found; nothing would have caught a second drift.The fix
packages/types/tsconfig.test.json, chained from the package'stype-checkscript — the shape this package already uses fortsconfig.examples.json: a separate, emit-free project.Kept separate rather than deleting the exclude, for a reason that matters: the reexport guard scans sibling sources off disk, so it needs
types: ["node"]. Folding that intotsconfig.jsonwould let package source reference Node APIs and still compile, in a package that ships to browsers.The 39 pre-existing errors it surfaced
p2-spec-exports.test.ts— 22. It imported eight…Schemanames as types from../index. #2561 decision (a) removed exactly those, and the siblingspec-ui-schema-reexports.test.tsasserts their absence — so this file contradicted its own guard for the whole interval. A type-only import of a nonexistent name erases at runtime, so the suite stayed green.Its fixtures were also typed as parsed output while being parse input — these schemas
.default()several fields, so{ enabled: true }is valid input but the output type requires them. They now usez.input<>, the distinction spec draws itself withActionInput. Same story foroperator: 'eq': a legacy alias spec folds at parse time, valid as input and absent from the canonical output union. The value-type re-exports this file exists to pin are now asserted explicitly, instead of incidentally through fixture annotations.app-creation-types.test.ts/system-fields.test.ts— 3. They imported the package by its own name.turbo'stype-checktask isdependsOn: ["^build"](upstream only), so the package's owndistdoes not exist when it runs. They now use the relative import all 13 sibling tests use.p1-spec-alignment.test.ts— 14, declared as debt rather than fixed. Excluded intsconfig.test.jsonwith a written reason, because these are not hygiene. Every one sits in a test namedshould accept <shape>whose entire purpose is asserting the type accepts that shape — and the type rejects it:ListViewSchema.sharingis{ type, lockedBy }. The legacy shape is real and is handled —foldSharingin core'snormalize-list-view.tsfoldsvisibility/enabledinto the spec'sViewSharing.type— but only as untyped input (normalizeListViewSchema<T>(schema: T): T), so no type names it. That is the same "implementation wider than the type" shape asexecute(objectstack#3856),navigation(#2944) and the param aliases (#3003).Each of the 8 sites is a separate decision — widen the type so the claim becomes true, or drop the claim — and several touch the public surface. Rewriting them silently while landing the plumbing would bury the finding, so they are tracked on objectstack#4074.
Scope
Deliberately narrow: only
packages/types, where the spec-derivation guards live. 28 other packages still exclude their tests; 5 (fields,cli,data-objectstack,plugin-charts,plugin-editor) already include them, so this establishes a pattern that is already load-bearing elsewhere rather than sweeping the repo.This also corrects an overstatement in #3003, which said every package tsconfig excludes tests. It is 33 of 41.
Verification
TS1360. Zero errors before.pnpm type-check— 76/76 tasks.pnpm vitest run— 717 files / 8380 tests passed, 1 file / 24 skipped.packages/types: all three tsconfig projects clean; 16 files / 246 tests.eslint packages/types/src— 0 errors (249 pre-existinganywarnings, none from this diff).node scripts/check-changeset-fixed.mjs— clean.Changeset is
patch: no public API changes, only build config and tests.Refs objectstack#4074, #3003, #2561, #2944, #2901, #2911
Generated by Claude Code