chore(deps): 把 @objectstack 家族同步到 17.0.0-rc.1,消除双版本 spec 图 - #3189
Merged
Conversation
#3178 bumped only @objectstack/spec to 17.0.0-rc.1. client/core/formula/lint depend on spec at an EXACT version, so main resolved two spec copies: objectui code saw rc.1 while every @objectstack/* package saw rc.0 from its own nested node_modules. That breaks the single-contract invariant the repo's guards rely on: spec-subschema-parity.test.ts distinguishes re-export from fork by reference identity, and check-spec-symbol-derivation.mjs / spec-symbol-parity.test.ts resolve spec's .d.ts via createRequire — with two copies, which one they see depends on resolution order. Raise the remaining ^17.0.0-rc.0 ranges to ^17.0.0-rc.1 so the floor is explicit. The rc.1 family members pin spec at 17.0.0-rc.1 exactly, so the graph converges on one copy by construction. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012C2cd7tL8QDoZ2QKN3djJ5
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 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
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 #3182
问题
#3178 只把
@objectstack/spec升到了17.0.0-rc.1,家族里其余包(client/core/formula/lint,以及经lint间接引入的sdui-parser)仍停在17.0.0-rc.0。而这几个包对 spec 的依赖是精确版本而非 caret:于是合并后的
main上同时躺着两份 spec:objectui 自己的代码读 rc.1,每个@objectstack/*包则从各自嵌套的node_modules里读 rc.0。这不只是「版本号不整齐」这么轻。本仓有多处 guard 建立在单一契约这个不变量上,而它们判定的依据是同一性、不是版本字符串,所以双份 spec 会让它们静悄悄地失准:
spec-subschema-parity.test.ts靠 zod schema 对象的引用同一性来区分「真 re-export」与「fork」。两份 spec 让每个 schema 都成了不同对象,于是真正的 re-export 会开始被读成 fork —— 或者反过来漏掉一个 fork,取决于两侧各自解析到了哪一份。scripts/check-spec-symbol-derivation.mjs与spec-symbol-parity.test.ts用createRequire解析 spec 的.d.ts再交给 TS checker。装了两份的时候,checker 究竟看到哪一份 declaration file,取决于解析顺序而不是意图。改动
把剩余的
^17.0.0-rc.0range 一并抬到^17.0.0-rc.1(packages/app-shell、packages/core、packages/data-objectstack、apps/console、apps/site),并刷新 lockfile。原先声明的 range 其实已经允许 rc.1 —— 钉死它的是 lockfile。抬 range 的意义在于把下限写明:今后任何一次 install 都不可能再悄悄滑回某个会顺手把 rc.0 拖进来的家族成员。rc.1 的家族成员把 spec 精确钉在
17.0.0-rc.1,所以现在的图是构造上收敛到一份,而不是碰巧收敛。没有产品行为改动。
验证
单份 spec 探针
图里只剩一份 spec。各家族包实际解析到的 spec:
lockfile 里
@objectstack/*的 snapshot key 也只剩 rc.1 一档(改前是spec@17.0.0-rc.0与spec@17.0.0-rc.1并存)。check:spec-symbols原正文「阻塞 2」的四处对账(
InboxNotification、FieldNode、以及JoinNode/PerformanceConfig两条陈旧 DEBT 台账)已由 #3178 全部处理完,统一到单份 spec 之后依然是绿的 —— 本 PR 无需再动spec-symbol-parity.test.ts或 DEBT 台账。$strip到$strict回归rc.1 把一批 zod schema 从
$strip翻成$strict(strict 会拒绝未知键而不是静默丢弃)。这批改动早在 #3178 就随 spec 落到 main 上了,本 PR 只是在统一图之后补做回归证明。在 rc.1 上实测各 subpath 的严格面(递归遍历 shape,统计 catchall 为never的 object schema):$strict$stripautomationui翻严的 schema 根落在这些族上:
FlowSchema/FlowNodeSchema/FlowEdgeSchema/FlowVersionHistorySchema、ApprovalNodeConfigSchema/ApprovalNodeApproverSchema/ApprovalEscalationSchemaAppSchema/AppBrandingSchema/AppContextSelectorSchema、DashboardSchema/DashboardNavItemSchema、FormViewSchema/FormButtonConfigSchema/FieldWidgetPropsSchema、以及整族导航项(NavigationContributionSchema、ObjectNavItemSchema、PageNavItemSchema、ActionNavItemSchema、ComponentNavItemSchema、GroupNavItemSchema、ReportNavItemSchema、UrlNavItemSchema)对应的解析面(
packages/types的 zod / parity 套件、app-shell 的 flow / approval / metadata-admin 套件、plugin-dashboard、plugin-form)都在全量 vitest 里跑到了,结果见下。没有出现「合法元数据现在被拒」的回归;若出现,按 contract-first 原则会另开 issue 记录而不是放松 schema。全量结果
全量 vitest(
pnpm test,unit / dom / dom-heavy / console 四个 project 全跑):针对「引用同一性」这条最容易被双份 spec 击穿的面,单独再跑一遍:
其余 gate:
未运行的套件:Playwright e2e(
test:e2e/test:e2e:live/test:e2e:import-*)—— 需要浏览器与实际后端服务栈,不在本次容器内运行(且按仓库多 agent 服务纪律不应占用共享端口)。这些是 CI 的职责。关于并行任务
#3181 正在给 app-shell 加
tsconfig.typetests.json与一条 CI lane;本 PR 未触碰这两处文件。本次对账无需修改spec-symbol-parity.test.ts,因此与 #3181 无文件重叠。版本策略
按 AGENTS.md「版本号策略」,changeset 标
minor—— fixed 组任一major都会把全组 40 个包推上去、脱离 objectstack 的节奏。🤖 Generated with Claude Code
Generated by Claude Code