test(plugin-calendar): partial-mock @object-ui/react so both vitest configs agree (#3219) (#3241)

`registration.test.tsx` whole-module-mocked `@object-ui/react` with just
`useSchemaContext` + `SchemaRendererContext`. That made the file's result
depend on how the module graph resolved, so the repo's two vitest configs
disagreed about it:

- root `vitest.config.mts` (CI): the file is in `heavyDomTests`, and
  `vitest.setup.dom.tsx` eagerly imports `@object-ui/components`, which
  evaluates `related-count-store.ts` (imports `subscribeDataChanges` from
  `@object-ui/react`) against the REAL module before the mock applies —
  green by accident.
- `packages/plugin-calendar/vitest.config.ts` (`pnpm --filter … test`,
  `turbo run test`): no such setup, so `@object-ui/components` is first
  evaluated inside the mocked graph. Vitest 4 hard-errors on a missing
  export, so the suite failed to load at all.

Switch to an `importOriginal` partial mock: the mock is now a superset of
the real module under either resolution, so a transitive consumer can never
trip over an export this test never intended to replace.

Add a regression guard asserting the mock exposes every real export. It
compares export SETS rather than naming `subscribeDataChanges`, so adding a
new `@object-ui/react` export cannot re-arm the same trap. Verified to fail
on the root path — the path where the original defect was invisible.


Claude-Session: https://claude.ai/code/session_01NVPjPzmmAJ2Ngtvgg5MSRa

Co-authored-by: Claude <noreply@anthropic.com>

Author: xuyushun441-sys

packages/plugin-calendar/src/registration.test.tsx

@@ -1,18 +1,43 @@
 import { describe, it, expect, vi } from 'vitest';
 import { render, screen } from '@testing-library/react';
 import React from 'react';
+import * as ObjectUIReact from '@object-ui/react';
 import { ObjectCalendarRenderer } from './index';
 
-// Mock dependencies
-vi.mock('@object-ui/react', async () => {
-  const React = await import('react');
-  return {
-    useSchemaContext: vi.fn(() => ({ dataSource: { type: 'mock-datasource' } })),
-    SchemaRendererContext: React.createContext(null),
-  };
-});
+// Partial mock — override ONLY what this test controls, keep every other real
+// export (objectui#3219).
+//
+// A whole-module `vi.mock('@object-ui/react', () => ({ ... }))` used to list
+// just `useSchemaContext` + `SchemaRendererContext`. That made the file's
+// result depend on HOW the module graph resolved, so the two vitest configs in
+// this repo disagreed about it:
+//
+//   - root `vitest.config.mts` (what CI runs): this file is in `heavyDomTests`,
+//     and `vitest.setup.dom.tsx` eagerly imports `@object-ui/components`. That
+//     evaluates `components/src/hooks/related-count-store.ts` — which imports
+//     `subscribeDataChanges` from `@object-ui/react` — against the REAL module
+//     before the mock applies. Green, by accident.
+//   - `packages/plugin-calendar/vitest.config.ts` (what `pnpm --filter … test`
+//     and `turbo run test` run): no such setup, so `@object-ui/components` is
+//     first evaluated inside the mocked graph. Vitest 4 hard-errors on a
+//     missing export instead of silently yielding `undefined`, so the suite
+//     failed to load at all: `No "subscribeDataChanges" export is defined on
+//     the "@object-ui/react" mock`.
+//
+// Spreading `importOriginal()` removes the sensitivity: the mock is a superset
+// of the real module under either resolution, so a transitive consumer can
+// never trip over an export this test never intended to replace. Adding a new
+// `@object-ui/react` export can no longer break this file.
+vi.mock(import('@object-ui/react'), async (importOriginal) => ({
+  ...(await importOriginal()),
+  // Only the pieces this test drives:
+  useSchemaContext: vi.fn(() => ({ dataSource: { type: 'mock-datasource' } })),
+}));
 
-// Mock the implementation
+// Mock the implementation. Deliberate whole-module replacement of a LOCAL
+// module: stubbing `ObjectCalendar` is the isolation boundary this test is
+// about, and `./ObjectCalendar`'s only runtime export is the component itself
+// (`ObjectCalendarProps` is type-only and erased at runtime).
 vi.mock('./ObjectCalendar', () => ({
   ObjectCalendar: ({ dataSource, data, loading }: any) => (
     <div data-testid="calendar-mock">
@@ -42,4 +67,27 @@ describe('Plugin Calendar Registration', () => {
     expect(el).toHaveTextContent('Data: [{"id":1,"name":"Event A"}]');
     expect(el).toHaveTextContent('Loading: false');
   });
+
+  // Regression guard for objectui#3219 — keep this test.
+  //
+  // It pins the exact invariant whose absence made the root config and the
+  // package config disagree about this file: the `@object-ui/react` mock must
+  // expose every export the real module has. When that holds, no transitive
+  // importer of `@object-ui/react` can hit a missing export, so the file
+  // behaves identically no matter which config resolved the module (source via
+  // the root alias, or `dist` via the package config) and no matter whether a
+  // setup file happened to pre-load the consumer first.
+  //
+  // Deliberately compares export SETS rather than naming `subscribeDataChanges`:
+  // naming the one export that broke would just re-arm the same trap for the
+  // next export somebody adds.
+  it('mocks @object-ui/react as a superset of the real module (pins both run paths to the same result)', async () => {
+    const actual = await vi.importActual<typeof ObjectUIReact>('@object-ui/react');
+
+    const missing = Object.keys(actual)
+      .filter((name) => !(name in ObjectUIReact))
+      .sort();
+
+    expect(missing).toEqual([]);
+  });
 });