feat(vue): add @modular-vue/testing (PR-12) - #60
Conversation
Port the testing helpers from @modular-react/testing to a new packages/vue-testing (@modular-vue/testing, 0.1.0): - createMockStore: identical createStore alias over @modular-frontend/core. - resolveModule: byte-identical to the React version (pure slot merging, dynamic-slot evaluation, onRegister, ModuleEntry assembly). - preloadEntries: walks each module's entryPoints and preloads every lazy entry via preloadEntry (re-exported from @modular-vue/vue). The synchronous-thenable trick from React.lazy does not port (matching the PR-11 resolve-entry.ts deviation): Vue's defineAsyncComponent resolves through its own async state, so preloadEntries warms the resolver cache but not the extra microtask. The React synchronous-resolution test is replaced by a cached-replay test; the vi.mock test asserts on the normalized component's displayName (Vue's preload() resolves to the unwrapped default). 15 tests pass (6 resolve-module, 9 preload-entries); typecheck and vite build (JS + dts) pass. Tracker updated: PR-12 done, Phase 1 complete.
|
Warning Review limit reached
Next review available in: 13 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (24)
📝 WalkthroughWalkthroughThis PR introduces a new ChangesVue testing package
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Test
participant preloadEntries
participant ModuleDescriptor
participant preloadEntry
Test->>preloadEntries: call(modules)
preloadEntries->>ModuleDescriptor: read entryPoints
loop each lazy entry
preloadEntries->>preloadEntry: preloadEntry(entry)
preloadEntry-->>preloadEntries: resolved import
end
preloadEntries-->>Test: Promise.all resolved
sequenceDiagram
participant Test
participant resolveModule
participant buildSlotsManifest
participant ModuleDescriptor
Test->>resolveModule: call(module, options)
resolveModule->>buildSlotsManifest: build(module, defaults)
buildSlotsManifest-->>resolveModule: slots
resolveModule->>ModuleDescriptor: evaluate dynamicSlots(deps)
ModuleDescriptor-->>resolveModule: merged slots
resolveModule->>ModuleDescriptor: onRegister(deps)
ModuleDescriptor-->>resolveModule: onRegisterCalled
resolveModule-->>Test: {slots, entry, onRegisterCalled}
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Address PR-12 review: resolveModule and createMockStore were byte-identical, framework-neutral copies in @modular-react/testing and @modular-vue/testing (pure over @modular-frontend/core). Extract them into a shared @modular-frontend/testing package that both bindings re-export, so slot resolution and mock-store fixes land in one place. Mirrors the earlier journeys-engine / compositions-engine extractions. preloadEntries stays per-binding since it imports the binding's preloadEntry. Also fix stale JSDoc that referenced React-only renderModule() in the Vue testing sources. - new packages/frontend-testing (@modular-frontend/testing 0.1.0) with mock-store, resolve-module, and the resolve-module test suite (6 tests) - @modular-react/testing and @modular-vue/testing re-export the neutral helpers, keep their own preload-entries (9 tests each) - build, typecheck, and tests pass for all three packages
…r-frontend/testing Extends the shared-testing extraction to the router bindings. @react-router-modules/testing and @tanstack-react-modules/testing carried their own byte-identical resolveModule (same slot-resolution logic, only the core import path and a doc line differed). Both now re-export it from @modular-frontend/testing; the router ModuleDescriptor is assignable to the shared generic, so caller ergonomics are unchanged (typecheck + suites pass). createMockStore stays local in each router package: it wraps zustand's createStore and returns StoreApi<T>, a different implementation than the frontend-core store, so it is not shareable. - delete resolve-module.ts from both router-testing packages (~69 lines each) - re-export resolveModule + option/result types from @modular-frontend/testing - point each resolve-module.test.ts at the shared package - add @modular-frontend/testing dep/peer + vite external to both - typecheck, tests (9 each), and build (JS + dts) pass for both packages
Phase 1 of the Vue support initiative, PR-12. Ports the testing helpers from
@modular-react/testingto a newpackages/vue-testing(@modular-vue/testing,0.1.0). See vue-support-tracker.md.React sources named per the working agreement (reviewers can diff intent):
mock-store.tstesting/src/mock-store.tsresolve-module.tstesting/src/resolve-module.tspreload-entries.tstesting/src/preload-entries.tspreload-entries.fixture.tstesting/src/preload-entries.fixture.tsWhat's here
createMockStore— identicalcreateStorealias over@modular-frontend/core.resolveModule(+ResolveModuleOptions/ResolveModuleResult) — byte-identical to the React version; it is pure (slot merging, dynamic-slot evaluation,onRegister,ModuleEntryassembly), all framework-neutral.preloadEntries— walks each module'sentryPointsand callspreloadEntry(re-exported from@modular-vue/vue) for everylazy:entry,Promise.all-ing them so one rejection doesn't leak sibling unhandled rejections.Depends on
@modular-frontend/core+@modular-vue/vue(the binding, for the preload path) plus avue ^3.5peer.Deviation from the React source (forced by the framework)
React.lazy's synchronous-thenable trick does not port, matching the PR-11
resolve-entry.tsdeviation. Vue'sdefineAsyncComponentresolves through its own async state on mount, sopreloadEntrieswarms the resolver'sWeakMapcache (saving the re-import) but not the extra microtask. Two adjustments in the ported test:vi.mockcase asserts on the normalized component'sdisplayNamedirectly, since Vue'spreload()resolves to the unwrappeddefault(React's resolved to the{ default }module record).Verification
pnpm --filter @modular-vue/testing test— 15 tests pass (6resolve-module, 9preload-entries).pnpm --filter @modular-vue/testing typecheck— passes.pnpm --filter @modular-vue/testing build— JS + dts emit clean.Summary by CodeRabbit
New Features
Documentation