mirror of
https://github.com/getpaseo/paseo.git
synced 2026-10-27 03:32:55 +00:00
* 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>
34 lines
1.2 KiB
TypeScript
34 lines
1.2 KiB
TypeScript
import { useCallback, type ReactNode } from "react";
|
|
import { PluginClientStateProvider, usePluginClientStateSource } from "./client-state.js";
|
|
import { PaseoApiProvider, usePaseoContextValue } from "./paseo-context.js";
|
|
import { PluginRpcProvider, usePluginRpcContextValue } from "./rpc-context.js";
|
|
|
|
export type PluginRuntimeContextBridge = (children: ReactNode) => ReactNode;
|
|
|
|
/** Rebuilds plugin runtime contexts inside React Native portal hosts. */
|
|
export function usePluginRuntimeContextBridge(): PluginRuntimeContextBridge {
|
|
const paseo = usePaseoContextValue();
|
|
const rpc = usePluginRpcContextValue();
|
|
const state = usePluginClientStateSource();
|
|
|
|
if (!paseo || !rpc) {
|
|
throw new Error("Plugin UI must run inside a contributed plugin surface");
|
|
}
|
|
|
|
return useCallback(
|
|
(children: ReactNode) => {
|
|
const content = state ? (
|
|
<PluginClientStateProvider source={state}>{children}</PluginClientStateProvider>
|
|
) : (
|
|
children
|
|
);
|
|
return (
|
|
<PaseoApiProvider paseo={paseo}>
|
|
<PluginRpcProvider invoke={rpc.invoke}>{content}</PluginRpcProvider>
|
|
</PaseoApiProvider>
|
|
);
|
|
},
|
|
[paseo, rpc, state],
|
|
);
|
|
}
|