fix(deps): declare the @objectstack/spec floor both artifacts actually require - #6368
Merged
Merged
Conversation
…y require `@object-ui/core` and `@object-ui/data-objectstack` declared `"@objectstack/spec": "^17.0.0"` while their shipped artifacts reference four symbols that version does not export — `FIELD_SORTABLE_UNPROVISIONED_ANCHOR`, `FIELD_UNSORTABLE_VIRTUAL_TYPE`, `FieldSortability` and `ObjectSortability` from `@objectstack/spec/api`. Both floors move to `^17.2.0`, which is `scripts/check-spec-range-floors.mjs`'s own computed answer for both packages. Measured on a fully built tree (`turbo run build --filter=!@object-ui/site`, 43/43 successful) either side of the change: `pnpm check:spec-floors` went from exit 1 with six `floor-too-low` findings across two published packages to exit 0 — "Every consumer-facing @objectstack/spec floor carries the symbols its package's artifact references." No source and no behaviour changes. `pnpm-lock.yaml` moves by exactly the two recorded `specifier:` lines; the resolved `version: 17.2.0` on both edges is unchanged, so nothing a consumer installs today differs. The gate forbids the tolerant alternative in its own remediation text: the range is the claim, and the claim is what was wrong. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011SfZeFWrhGLHmfq61xbz4q
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
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.
Fixes #6361
What
packages/core/package.jsonandpackages/data-objectstack/package.jsonnow declare"@objectstack/spec": "^17.2.0"instead of^17.0.0. Both shipped artifacts referencesymbols
@objectstack/spec@17.0.0does not export, so the declared range was a falsepublic claim about what these packages work against.
^17.2.0is not taken on trust from the card: it isscripts/check-spec-range-floors.mjs'sown computed answer, printed by the red run and confirmed by the gate's verdict after the
change. The tolerant alternative the gate forbids verbatim — "Do not add a tolerant
re-declaration on this side: the range is the claim, and the claim is what is wrong" — is
not used. No source file is touched.
Why this is release-blocking rather than cosmetic.
spec-range-floors.ymlis deliberatelynot a
pull_requestjob, so every PR stayed green while the blocking copy on the publish path—
pnpm changeset:publishruns this gate before a single tarball reaches npm — would havecancelled the next release.
The two gate readings
The gate needs a full workspace build to answer at all; run before one it returns
[no-artifact], a prerequisite-not-met failure that reads exactly like a red gate. Bothreadings below sit on top of the build the gate itself prescribes, and both name the
population they judged, which is identical either side:
1. Red before —
pnpm check:spec-floors→ exit 1Build first:
pnpm exec turbo run build --filter='!@object-ui/site'→Tasks: 43 successful, 43 total(Time: 7m59.478s).That is the gate's own answer to the range question, and it is what this PR writes.
2. Green after —
pnpm check:spec-floors→ exit 0Rebuilt after the edit (
Tasks: 43 successful, 43 total,Time: 5m41.886s), then:The CI-exact invocation
pnpm check:spec-floors -- --cross-checkis green too, and adds itsown line:
The green run also reports reading
@objectstack/spec@17.2.0's.,./api,./contracts,./dataand./uientry points — i.e. the new floor is what it actually judged, not theinstalled tree.
T3 — the complete finding list, from the full-workspace run
The six findings quoted above are the whole list: the run inspected all 19 of the 39
published packages that declare
@objectstack/specin a consumer-facing field, across 2028artifact files, and flagged only these two packages.
@object-ui/plugin-detailalready sits at^17.1.0(raised by objectui#5793) and is clean; every other spec-declaring package is clean at^17.0.0. Nothing is pre-emptively bumped — only what the gate reported.For completeness, the packages that declare the spec only in
devDependencies(
collaboration,mobile,plugin-charts,plugin-dashboard,plugin-report,runner,sdui-parser,console,test-support) are out of the gate's scope by design: adevDependenciesrange is not installed for anybody and floors nothing.T2 — the installed spec version
17.2.0. Read two ways in this worktree:That matters for the prerequisite: the build that produced the artifacts the gate judged was
compiled against 17.2.0, which is exactly the version the new floor names — so the artifact
read is the artifact a normal consumer install gets, and the red reading is a floor-honesty
finding rather than an artifact-mismatch artefact.
T1 — the lockfile did move, and that is part of the change
pnpm installafter the manifest edit changedpnpm-lock.yamlby exactly two lines, bothrecorded
specifier:values underimporters:. The resolved version on both edges isuntouched:
@@ importers: packages/core '@objectstack/spec': - specifier: ^17.0.0 + specifier: ^17.2.0 version: 17.2.0(ai@7.0.65(zod@4.4.3)) @@ importers: packages/data-objectstack '@objectstack/spec': - specifier: ^17.0.0 + specifier: ^17.2.0 version: 17.2.0(ai@7.0.65(zod@4.4.3))It is included deliberately, not as a stray edit: every CI job installs with
pnpm install --frozen-lockfile, which fails when a manifest range and the recorded specifierdisagree. Nothing a consumer installs today differs — resolution already landed 17.2.0 on both
edges before the bump.
T4 — no behaviour changes
Four files, none of them source:
packages/core/package.json^17.0.0→^17.2.0packages/data-objectstack/package.json^17.0.0→^17.2.0pnpm-lock.yamlspecifier:lines (above).changeset/6361-spec-floor-17-2-0.mdpatchfor both packagespackages/data-objectstack/src/**is untouched — that surface belongs to the open PR #6363.The changeset, and what the presence gate actually said
node scripts/check-changeset-presence.mjs→ exit 0, verdict line:It does not demand one: its own header records that
package.jsonitself never counts.A changeset is added anyway, and the reason is the point of the card — without a version bump
these two packages never re-publish, so the corrected manifest would never reach npm and the
false floor would stay in the published tarballs. Scored
patchfor both packages, on the samereasoning objectui#5793 used for the identical remediation on
@object-ui/plugin-detail. Nevermajor(fixed group of 39).Gates
Gate set derived by reading the CI job step lists under
.github/workflows/and keeping thesteps whose inputs this diff actually moves — published-package manifests,
pnpm-lock.yaml, andone
.changeset/*.md. Union re-run after the final commit, on20caed9c9, with a cleanworking tree; each row quotes the gate's own verdict line, and each exit code was captured
before any pipe.
pnpm check:spec-floors -- --cross-checkspec-range-floors.yml· Verify every declared spec floor carries the symbols its artifact uses✅ Every consumer-facing @objectstack/spec floor carries the symbols its package's artifact references.node scripts/check-changeset-presence.mjschangeset-presence.yml· Verify a changeset declares this change✅ No source of a released package changed in this range, so no changeset is owed.node scripts/check-changeset-no-major.mjschangeset-guard.yml· Verify no changeset declares a major bump✅ No changeset declares a `major` bump.node scripts/check-changeset-fixed.mjsci.yml· Verify all packages are in changeset fixed group✅ All workspace packages are in the changeset fixed group.node scripts/check-control-bytes.mjscontrol-bytes.yml· Scan tracked text files for raw control bytes✅ check-control-bytes: OK (scanned 5239 tracked text file(s); skipped 85 binary).pnpm check:phantom-depsci.yml· Verify every imported package is declared by the package that ships it✅ Every in-scope import is declared by the package that publishes it.pnpm exec turbo run build --filter='!@object-ui/site'spec-range-floors.yml· Build every published packageTasks: 43 successful, 43 totalDeclared narrowing — stated as "not run", not as a measured narrowing. The repo-wide
scans in
ci.yml/lint.ymland the artifact farm (pnpm lint,pnpm test,pnpm type-check,check:published-dist,check:node-esm-load,check:readme-exports, thedoc-*/i18n-*gates,
check:eager-closure, E2E, performance budget) were not run locally. This is adeclaration, not a proof of equivalence: the justification is only that this diff moves no
source, no doc, no locale and no bundle input, and CI runs the whole farm on this head anyway.
Generated by Claude Code