Uh oh!
There was an error while loading. Please reload this page.
refactor(plugin-calendar): rename the runtime CalendarEvent to CalendarViewEvent, keep a deprecated alias (#5044) - #5866
Merged
Conversation
…endarViewEvent` (#5044) Two structurally incompatible public exports were both called `CalendarEvent`: the AUTHORING event in `@object-ui/types` (`id: string`, ISO-string `start`/`end` with `end` required, plus `description`) and this package's RUNTIME event (`id: string | number`, `start: Date`, `end?: Date`). Neither is assignable to the other, so IDE auto-import picked between them at random and the wrong pick failed as a remote `TS2322` about `Date`, not as a wrong import. Per the 2026-08-19 maintainer ruling (option A), the authoring type keeps the canonical name and the runtime type is renamed, with a `@deprecated` `CalendarEvent` alias left on the barrel — the same shape objectui#4650 used for `ObjectCalendarProps` -> `ObjectCalendarComponentProps`. The alias is a working re-export of the same type, so existing importers keep compiling; no behaviour changes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EuPCi56cnGyykygi3z9w4m
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
|
os-zhuang
marked this pull request as ready for review
August 23, 2026 16:46
Uh oh!
There was an error while loading. Please reload this page.
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 freeto 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#5044
Executes the 2026-08-19 maintainer ruling (option A, 「全部接受」): the authoring type keeps the canonical name, the runtime type is renamed, and a
@deprecatedalias is left behind — the same shape #4650 used forObjectCalendarProps→ObjectCalendarComponentProps.What moved
@object-ui/types— AUTHORING event (id: string, ISO-stringstart/endwithendrequired, plusdescription)CalendarEventCalendarEvent— unchanged, keeps the canonical name@object-ui/plugin-calendar—CalendarView's RUNTIME event (id: string | number,start: Date,end?: Date)CalendarEventCalendarViewEvent, plusCalendarEventas a@deprecatedaliasThe published
.d.tscarries both, with the deprecation intact:grep 'interface CalendarEvent' packages/plugin-calendar/dist/*.d.tsnow returns nothing — the old name survives only as a re-export of the new one.Non-breaking, by construction rather than by assertion. At the package boundary this change is strictly additive: before, the barrel exported
CalendarEvent; after, it exportsCalendarEvent(aliased) andCalendarViewEvent. No name was removed and no shape changed, so no consumer has a narrowed surface to fail on. That is why option B (stop exporting the runtime type) is not what landed.Acceptance evidence is about the published NAME SET, not behaviour
Nothing here changes what a calendar renders, and no test claims it does. The new pin is
packages/plugin-calendar/src/__tests__/name-collision-5044.test.ts, sibling ofspec-symbol-4650.test.tsnext door. It is compiled by this package'stsconfig.test.json, which drops the rootpaths— so@object-ui/typesresolves through the workspace dependency's built.d.ts, the surface a consumer actually imports. Proved rather than assumed:What it pins:
idandstarteach conflict) — the trap itself, not just its symptom;CalendarViewEvent— a type-only stub (= never, a re-declaration) fails here;@object-ui/typesstill declaresCalendarEvent— the "which type moved" invariant, so a future edit cannot silently invert this card.Legs that do not discriminate, named rather than written: rendering a
CalendarViewis green before and after under either name (it measures the component, not the name set);typeof CalendarEventat runtime probes nothing, because both are types and are erased before vitest loads the file — which is exactly why the pins are compile-time.Reverse verification (on the committed tree, mutation confirmed on disk each time)
Ablation 1 — delete the deprecated alias from the barrel (the "Option B by another route" failure). Predicted: type-check red on the old-name import; vitest red on the deprecation-tag test only.
Observed exactly as predicted, including the non-discriminating half: the type-level
itpassed under vitest, because its assertions are erased there.Ablation 2 — the cross-package leg, mutating the AUTHORING type's
id: string→string | numberinpackages/types/src/complex.ts. This one exists to prove the pins read the rebuilt.d.tsrather than a cache, so both legs rebuild and both are confirmed indist:Every mutation was confirmed by grepping the text it was meant to change, never by an editor's exit code; both ablation scripts carried a
trap … EXIT INT TERMrestore.Also in this diff, and why
packages/plugin-calendar/src/ObjectCalendar.tsx— droppedtype CalendarEventfrom its./CalendarViewimport. The identifier appeared exactly once in the file, on the import line itself (grep -cw→ 1), so it had no reader; renaming it would have left a name nothing spells. Called out here rather than left silent.content/docs/plugins/plugin-calendar.mdx— the docs half of this rename (AGENTS.md Add automated testing infrastructure and CI/CD workflows #2). The README's "two same-name types" note now names both types and records the alias. The docs page's TypeScript Support block was a second live instance of the very defect this card fixes: it annotated a runtime-shaped literal (id: 1,start: new Date(...)) asCalendarEventimported from@object-ui/types, which is the authoring type that rejects both. It now importsCalendarViewEventfrom this package. The block is fenced```plaintext, socheck:doc-snippet-typesnever read it — that is why it outlived plugin-calendar README 教的calendarComponents手动注册 API 不存在 —— 照抄即抛 #5010.onEventClick?: (event: CalendarEvent) => voidis left alone: that isCalendarViewSchema's host-only callback, whose payload really is the@object-ui/typesauthoring type.Verification — union re-run on the final commit
d9d13e7fapnpm --filter @object-ui/plugin-calendar type-check(tsc --noEmit && tsc -p tsconfig.test.json)pnpm exec vitest run --maxWorkers=2 packages/plugin-calendar/src(repo root)Test Files 12 passed (12)/Tests 86 passed (86)pnpm exec vitest run scripts/__tests__/{doc-version-claims,check-doc-links,vitest-invocation-guard,check-changeset-presence}.test.tsTest Files 4 passed (4)/Tests 166 passed (166)node scripts/check-changeset-presence.mjs✅ 7 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)node scripts/check-doc-snippet-types.mjsSemantic phase: 101 of 101 block(s) judged, 0 failed.pnpm check:doc-types✅ Every documented component type is registered.pnpm check:spec-symbols✅ spec symbol derivation: … 13 declared dialects, 3 untriaged collisions in 1 packages.(unchanged — neither name collides with a spec export)pnpm check:control-bytes✅ check-control-bytes: OK (scanned 4882 tracked text file(s); skipped 85 binary).pnpm check:self-import/check:phantom-deps✅/✅node scripts/check-type-check-coverage.mjs✅ 45/46 …and✅ test type-check coverage: 41/41 packages compile their testsnode scripts/check-lint-coverage.mjs✅ lint coverage: 46/46 packages linted, 0 with outstanding errorsnode scripts/check-doc-links.mjsLinks are valid across 13 scan roots.Lint is a declared narrowing, not the repo-wide run — CI runs the farm regardless. Evidence that the narrowing excluded nothing: (1) the population came from eslint's own enumeration, not a guess —
eslint --no-inline-config --format json packages/plugin-calendarenumerated 20 files, all seven changed/added source files among them; eslint itself refusedcontent/docsand.changesetwith "all of the files matching the glob pattern are ignored", so those two edits are outside the lint population by its configuration; (2) the file count is read from--format json, not counted by hand; (3) type-aware linting is off —eslint --print-configon the barrel printsparserOptions: {}(noproject/projectService), so this diff cannot move the verdict of any file it does not touch. Result: 0 error-severity messages (106 pre-existing warnings, unchanged in kind).Nothing was widened, no pin loosened, no assertion weakened, no exemption added.
Generated by Claude Code