* fix(plugins): keep React out of the server plugin host * fix(plugins): align SDK guidance and tests with runtime boundaries * fix(plugin): loosen the react peer to ~19.1.0 The plugin SDK pins its react peer to exactly 19.1.0, and that pin is what a downstream `npm i -g @getpaseo/cli` resolves against. So every user ends up with react 19.1.0 in their global node_modules, where corporate dependency scanners flag it: the CVE-2025-55182 advisory range covers 19.1.0 even though the vulnerability itself lives in react-server-dom-webpack/-parcel/-turbopack, none of which the CLI installs. The user is then left hand-patching node_modules or uninstalling Paseo. Widening the peer to ~19.1.0 lets a downstream install pick the latest 19.1.x patch (19.1.9 today) while this repo stays on 19.1.0, which the root override still pins. Keeping the repo itself on 19.1.0 is deliberate. react-native 0.81.5 embeds a 19.1.0 Paper renderer that hard-throws "Incompatible React versions" on any exact mismatch, and it is reachable from Fabric builds too: RendererImplementation.js requires the Paper shim unconditionally in findNodeHandle, unstable_batchedUpdates, sendAccessibilityEvent and three other entry points, and react-native-gesture-handler re-exports findNodeHandle. Bumping the app's react is therefore not safe until react-native moves. The published CLI tree contains no react-native, so downstream installs are not subject to that constraint. Supersedes the earlier 19.1.5/19.1.9 version-bump approach on this branch, which would have broken the mobile app. * Enforce example import ownership including client types * Update Nix dependency hash for plugin peer metadata * Group plugin APIs under client and server entry trees * Resolve plugin type dependencies through declarations * Validate declarations for implicit plugin type imports * Preserve optional imports and validate declaration references * Refresh Nix hash for plugin declaration resolver * Canonicalize plugin paths consistently on Windows * Normalize plugin ownership paths across resolver boundaries --------- Co-authored-by: liujin0506 <liujin0506@qq.com> Co-authored-by: Mohamed Boudra <boudra.moha@gmail.com>
Modal UI example
Install this directory as a local plugin, then open Modal examples from the sidebar or a workspace tab.
The examples demonstrate default and custom padding, a full-width body, author-owned ScrollView and FlatList scrolling, horizontal tabs, and clipboard actions with a keyboard-aware input. See the host UI reference for the API contract.
The browser regression installs this exact example in an isolated daemon:
cd packages/app
npx playwright test e2e/browser/plugin-modal-body.spec.ts --project=browser --workers=1
On Android, open each example and drag up on its content to expand the sheet, then scroll the list. In FlatList, expand before using Jump to last row; row 100 should be visible. At the top of either list, drag down on a row to dismiss the sheet. In Form, press Copy text, long-press the input, and choose Paste. The input should contain “Copied from Paseo”. With the system keyboard enabled, focusing the input should keep it visible.
Run the native sheet regression to check body dismissal, list scrolling and horizontal tabs together.
These captures show Android copy/paste and custom padding on browser and wide native layouts. Android API 35 and Chromium were exercised; iOS and Electron were not tested.
| Android copy/paste | Browser custom padding | Wide Android custom padding |
|---|---|---|
![]() |
![]() |
![]() |


