@ic-reactor/mcp 0.0.0-stage → 0.0.0

package/packages/mcp/tsconfig.json

@@ -0,0 +1,19 @@
+{
+  "extends": "../../tsconfig.base.json",
+  "compilerOptions": {
+    "outDir": "./dist",
+    "rootDir": "./src",
+    "declaration": false,
+    "sourceMap": true,
+    "noEmit": false,
+    "allowImportingTsExtensions": true,
+    "rewriteRelativeImportExtensions": true,
+    "target": "ES2022",
+    "lib": ["ES2023"],
+    "module": "NodeNext",
+    "moduleResolution": "nodenext",
+    "types": ["node"]
+  },
+  "include": ["src/**/*"],
+  "exclude": ["**/*.test.ts", "tests/**/*"]
+}

package/packages/mcp/tsconfig.typecheck.json

@@ -0,0 +1,10 @@
+{
+  "extends": "./tsconfig.json",
+  "compilerOptions": {
+    "noEmit": true,
+    "rootDir": ".",
+    "types": ["node"]
+  },
+  "include": ["src/**/*", "tests/**/*"],
+  "exclude": ["node_modules", "dist"]
+}

package/packages/mcp/vitest.config.ts

@@ -0,0 +1,10 @@
+/// <reference types="vitest" />
+import { defineConfig } from "vitest/config"
+
+export default defineConfig({
+  test: {
+    environment: "node",
+    globals: true,
+    include: ["src/**/*.test.ts", "tests/**/*.test.ts"],
+  },
+})

package/packages/react/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2023-2026 Behrad Deylami
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/packages/react/README.md

@@ -0,0 +1,328 @@
+# @ic-reactor/react
+
+> **This is ic-reactor 4.** 3.x, with its hook factories and auth hooks, is
+> documented at https://ic-reactor.b3pay.net/v3/packages/react and takes
+> security fixes until 90 days after the 4.0 release.
+
+[![npm version](https://img.shields.io/npm/v/@ic-reactor/react.svg)](https://www.npmjs.com/package/@ic-reactor/react)
+[![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](https://opensource.org/licenses/MIT)
+
+The React bindings of ic-reactor 4: three `'use client'` exports over a client
+made by [`@ic-reactor/core`](../core/README.md).
+
+| Export            | What it is                                                               |
+| ----------------- | ------------------------------------------------------------------------ |
+| `ReactorProvider` | Gives a tree one client, and TanStack Query that client's `QueryClient`. |
+| `useClient`       | The client of the nearest provider, for the caller this render shows.    |
+| `useAuth`         | Who calls (`status`, `principal`), with `signIn` and `signOut`.          |
+
+There is no hook that wraps `useQuery` or `useMutation`: read and write
+canisters with TanStack Query's own hooks and the options the client builds.
+The package never re-exports `@ic-reactor/core`, so every name has one import
+path. The guide for both packages ships in core:
+`node_modules/@ic-reactor/core/llms.txt`. The docs site covers the same ground
+in pages, starting with
+[Getting started](https://ic-reactor.b3pay.net/v4/guides/getting-started/),
+and [this package's page](https://ic-reactor.b3pay.net/v4/packages/react/)
+lists its exports and peers.
+
+## Install
+
+```bash
+npm install @ic-reactor/core @ic-reactor/react @tanstack/react-query
+```
+
+Peers: `react` 18 or newer, `@tanstack/react-query` 5, and `@ic-reactor/core` at
+exactly this package's version (the two are released together). Install core's
+own peers and the generator as [core's README](../core/README.md#install) says:
+`@icp-sdk/core`, and the schema runtime and its CLI at the exact versions it
+names.
+
+Install `@tanstack/query-core` (a peer of core) at the exact version your
+`@tanstack/react-query` depends on (`npm view @tanstack/react-query@<version>
+dependencies`), and check that `npm ls @tanstack/query-core` shows one copy.
+With two copies, core and the hooks each have their own `skipToken`:
+`client.queryOptions()` throws a `TypeError` for the hooks' one, and in
+development `ReactorProvider` throws when it is handed such a client.
+
+## Provide a client
+
+`ReactorProvider` takes a factory, not a client, and calls it once for each
+mounted provider. When it unmounts, it disposes the client only if that factory
+call created it. Both ways of writing the factory are fine:
+
+- **The provider owns the client.** A factory that creates it,
+  `client={() => createClient({ ... })}`, gives each mounted provider a client
+  of its own, and the provider disposes it when it unmounts. Use this in an
+  app that renders on a server: the factory runs once per request.
+- **The app owns the client.** A client created at module scope, one per tab
+  and used outside React too, is handed over as `client={() => client}`. The
+  provider borrows it and never disposes it, however many times it mounts and
+  unmounts: the app decides when it ends.
+
+`createClient` does no work until the client is used, so the same line runs in
+a server render (anonymous, no auth built) and in the browser (signed in).
+
+```tsx
+"use client"
+
+import { createClient } from "@ic-reactor/core"
+import { ReactorProvider } from "@ic-reactor/react"
+import { AuthClient } from "@icp-sdk/auth/client"
+import type { ReactNode } from "react"
+
+export function Providers({ children }: { children: ReactNode }) {
+  return (
+    <ReactorProvider
+      client={() =>
+        createClient({
+          network: "ic",
+          auth: (network) => new AuthClient(network),
+        })
+      }
+    >
+      {children}
+    </ReactorProvider>
+  )
+}
+```
+
+Render it at the root of the part of the app that calls canisters. In a
+framework that renders Server Components, keep the factory in a client module
+like this one: a function cannot cross from a Server Component into a client
+one, so `<Providers>` is what the server layout renders.
+
+A client the app owns, in a browser-only app:
+
+```tsx
+"use client"
+
+import { createClient } from "@ic-reactor/core"
+import { ReactorProvider } from "@ic-reactor/react"
+import { AuthClient } from "@icp-sdk/auth/client"
+import type { ReactNode } from "react"
+
+// One client for this tab, also used outside React.
+export const client = createClient({
+  network: "ic",
+  auth: (network) => new AuthClient(network),
+})
+
+export function Providers({ children }: { children: ReactNode }) {
+  return <ReactorProvider client={() => client}>{children}</ReactorProvider>
+}
+```
+
+Who owns a client follows from when it was created, not from where the factory
+is written. A getter that creates the shared client on its first call
+(`client ??= createClient(...)`) makes the first provider that calls it the
+owner, and that provider disposes it when it unmounts. It can lose the client
+even before that: when React throws away the render that created it (a
+Suspense boundary above the provider that suspends), the client stays queued
+for disposal at garbage collection until the next render gets it back, so a
+collection while the fallback shows disposes the client the page then mounts
+(see [Life of the client](#life-of-the-client)). Create a shared client
+eagerly, as above. In development, a provider whose factory hands back a client
+that an earlier factory call created and no provider has committed yet, as a
+lazily shared getter does, logs a warning that names the fix (under
+`StrictMode`, which calls the factory twice, on the first render); and a
+provider that is given a client which is already disposed logs an error.
+
+An app that already uses TanStack Query keeps one `QueryClient` per tree,
+the client's. `ReactorProvider` provides `client.queryClient`, so the app's own
+queries, REST calls included, run on it: an error that is not a `ReactorError`
+is retried as TanStack Query retries it by default (up to 3 times in a
+browser, never on a server), and `client.dispose()` clears those queries
+along with the client's reads. Set other defaults on each query. A
+`QueryClientProvider` of the app's own nested inside the provider works too: a
+write invalidates its reads on the `QueryClient` it ran on as well as on the
+client's. That `QueryClient` lacks the client's dehydrate and hydrate defaults,
+so a server render dehydrates `client.queryClient`.
+
+## Who is signed in
+
+```tsx
+import { useAuth } from "@ic-reactor/react"
+
+export function SessionButton() {
+  const { status, principal, signIn, signOut } = useAuth()
+  return status === "signed-in" ? (
+    <button onClick={() => signOut().catch(console.error)}>
+      Sign out {principal}
+    </button>
+  ) : (
+    <button onClick={() => signIn().catch(console.error)}>Sign in</button>
+  )
+}
+```
+
+`status` is `"anonymous"`, `"signed-in"`, `"expired"` or `"signed-in-elsewhere"`,
+and `principal` is the principal calls go out as: the anonymous principal
+(`2vxsx-fae`) in every state but `"signed-in"`. While signed in through an
+auth that reports when the session ends, as `AuthClient` 10 does, `expiresAt`
+is that time in milliseconds since the epoch. A component that uses
+`useAuth()` renders once for each change of status, principal or `expiresAt`
+(a session that ends by the clock included, with no user activity), and never
+for anything else; the object it returns is the same until one changes.
+`"signed-in"` may be a read-only session, which the network refuses updates
+from: `@icp-sdk/auth` does not expose the scope yet.
+
+## Keys follow the caller a render shows
+
+Query keys carry the caller. Call `useClient()` in the body of each component
+that builds keys or read options, on every render, and build them from what it
+returns there, never from a client held at module scope. It returns a view of
+the client for the caller the render shows: one object per caller, a new one
+after a sign-in, a switch of account or a sign-out, and the same one on every
+render while the caller stays. List it in the dependencies of what is built
+from it (`useMemo(() => client.queryOptions(...), [client])`, an effect, a
+callback, as the `react-hooks/exhaustive-deps` lint rule asks); React Compiler
+memoizes on it the same way. Either way, what is memoized is built again for
+the new caller, and never shows the previous caller's data.
+
+Its `queryKey`, `queryOptions`, `caller()` and `authState()` are that caller's,
+and its `mutationOptions` send only as that caller: a write pressed before a
+switch reaches the render is refused (`kind` `"cancelled"`, `code`
+`"caller_changed"`, `mayHaveExecuted: false`) and sends nothing, so a click
+handler needs no check of its own. Their `mutationKey` ends with that caller. A
+handler that awaits `signIn()` and then calls `mutate` presses with the last
+committed render's options, and is refused if the signed-in render has not
+committed yet (one that suspends on the user's data): let the next render
+press, or make a direct call. A canister's direct calls sign as the caller
+current when they run. Canisters, `signIn`, `signOut` and the `QueryClient` are
+the client's own. It is never the provider's client object: to tell two clients
+apart, compare their `queryClient`.
+
+Do not keep what it returns past the render: a view never moves on. Kept
+anywhere else (`useState(client)`, `useRef(client)`, a `useMemo` or
+`useCallback` with `[]`, a module variable), it stays the view of the caller it
+was taken for: the component shows that caller's data, a read it starts while
+someone else is signed in is cancelled (`caller_changed`), and a write through
+it is refused. Nothing warns about it. A nested `ReactorProvider` given it
+holds the client the view was made over.
+
+```tsx
+import { useClient } from "@ic-reactor/react"
+import { useQuery } from "@tanstack/react-query"
+import { actor, type Actor } from "./generated/icrc1"
+
+export function Fee({ id }: { id: string }) {
+  const client = useClient()
+  const ledger = client.canister<Actor>(actor, { id })
+  const fee = useQuery(client.queryOptions(ledger, "icrc1_fee"))
+  return <span>{fee.data?.toString() ?? "…"}</span>
+}
+```
+
+`useClient()` follows the client's caller, so a component that calls it renders
+again on a sign-in, a switch of account and a sign-out, and builds the new
+caller's keys; a change of status that leaves the caller as it is (a session
+that expired, or one signed in elsewhere, both call anonymously) renders
+nothing and returns the same view. A client built with `identity` keeps its
+caller for good and is always returned as it is.
+
+## On a server
+
+- **One client per request.** A server renders each request as a tree of its
+  own, so a factory that creates the client runs once per request, and no
+  cache or caller is shared between two users. Never build the client at
+  module scope on a server: a module-scope client is for a browser-only app.
+- **Anonymous while hydrating.** `useAuth()` is `anonymous` on a server and
+  while a page hydrates, even when the browser holds a session: the server has
+  none, and the HTML has to match. `useClient()` builds keys for that same
+  anonymous caller there: in a browser that holds a session (an `AuthClient`
+  reads a stored one synchronously), the hydrating render gets the anonymous
+  caller's view, so the page finds what the server prefetched and dehydrated,
+  matches its HTML, and sends nothing. Right after hydrating, React
+  renders each component that calls `useClient()` or `useAuth()` again with
+  the session, and each read loads the user's keys once: until the user's data
+  arrives, a read shows its loading state, and a `useSuspenseQuery` read its
+  boundary's fallback. A tab whose caller
+  is anonymous anyway (no session, or one that expired or is signed in
+  elsewhere) renders no `useClient()` component again, and no `useAuth()`
+  component either unless its status differs. Show the same thing signed out
+  and while the session is read, and the page does not flicker into a
+  different layout.
+- **Nothing runs on a server but the render.** The auth factory is never called,
+  nothing reads `window` or `localStorage`, and no effect runs, so no timer or
+  listener outlives the request.
+
+### What a signed-in reload costs
+
+Three consequences of that move to the session are accepted, and tested:
+
+- **A Suspense boundary still dehydrated below a component that renders with
+  the caller is rendered on the client.** When a component that calls
+  `useClient()` or `useAuth()` moves on to the session, the update reaches the
+  boundaries it renders. A boundary that has not hydrated yet, because its
+  lazy code is still loading or its streamed HTML has not arrived, is then
+  rendered on the client: it shows its fallback instead of
+  the server's HTML until its content is ready, and React 18 reports a
+  recoverable error. Its data is still the user's, and nothing is sent as
+  anyone else. A `useAuth()` component moves on, and costs the same, in a tab
+  whose session expired or is signed in elsewhere too. To keep the server's HTML, render such a boundary where no
+  component that renders with the caller sits above it (a `useAuth()` header
+  beside it is fine), or pass it in as `children`: a component's own update
+  does not render its `children` prop again.
+- **A read the hydrating render built may run once and be cancelled.**
+  TanStack Query refetches stale data on mount, and an effect may fetch with
+  the hydrating render's options. Such a read is for the anonymous caller
+  while the user is current, so it is cancelled before anything is sent. A
+  key that holds data (the server's) keeps it as it was, and a fetch of it
+  resolves with that data. A key with none fails, with `kind` `"cancelled"`
+  and `code` `"caller_changed"`, until the anonymous caller is current again.
+  The hydrating render's own reads never show that error, but a global
+  error listener, an effect that awaits the fetch and, for a
+  `useSuspenseQuery` read the server rendered without dehydrating its data,
+  React's `onRecoverableError` (as the reported error's `cause` on React 19)
+  see it: ignore `kind` `"cancelled"` there. The client owns its
+  `QueryClient` and takes no `QueryCache`, so a global listener is
+  `client.queryClient.getQueryCache().subscribe()`, which sees the error as
+  an `"updated"` event whose `action.type` is `"error"`.
+- **A `useSuspenseQuery` read needs a Suspense boundary above it, on React 18
+  and 19 alike.** The move to the session is a synchronous update, and a
+  `useSuspenseQuery` read with none of the user's data yet suspends it. With a
+  boundary above the read, the boundary shows its fallback until the user's
+  data arrives, then the data, and the rest of the page responds meanwhile.
+  With none, React 18 refuses the update ("A component suspended while
+  responding to synchronous input") and unmounts the root: a signed-in reload
+  renders nothing. React 19 keeps the server's HTML on screen, but until the
+  user's data arrives, however long the read and its retries take, a click or
+  any other update outside a transition commits nothing, and neither does a
+  transition that renders the reading component again. React expects a
+  boundary above any component that suspends anyway: put one there.
+
+## Life of the client
+
+The provider disposes a client its factory created when it unmounts: the
+client stops listening to the auth, disposes it, and clears the `QueryClient`.
+React's development double-mount (`StrictMode` unmounts and mounts every
+component at once) does not dispose a client in use, because the disposal is
+scheduled for the next macrotask and the second mount cancels it. A client the
+app owns is never disposed by a provider.
+
+React runs no cleanup for a render it throws away before committing it, such
+as a provider's first render below a Suspense boundary that suspends. A client
+the factory built for such a render, whose auth a `useAuth()` below may
+already have built, is disposed once that render's state is garbage collected
+(through a `FinalizationRegistry`, in a browser): later than an unmount would,
+but its auth and listeners do not outlive it. A client the factory returns
+again, or that a mounted provider runs on, is never disposed this way, whoever
+created it.
+
+Only the factory of the first render is used: passing another function on a
+later render does not rebuild the client. To replace the client, give the
+provider another `key`.
+
+When React shows a hidden `Activity` again after the client the provider owns
+was disposed, the provider builds another one with the same factory. That
+client starts with an empty cache: hiding a provider inside an `Activity` drops
+everything it had fetched, because React cannot tell a hidden subtree from an
+unmounted one when it cleans up. To keep the cache across hiding, render the
+provider above the `Activity`, or give it a client the app owns.
+
+## 3.x
+
+The released 3.x package, with its hook factories and auth hooks, is documented
+at https://ic-reactor.b3pay.net/v3/packages/react. Its source and security fixes
+live on the `v3` branch.

package/packages/react/llms.txt

@@ -0,0 +1,95 @@
+# @ic-reactor/react
+
+> The React bindings of ic-reactor 4: `ReactorProvider`, `useClient` and
+> `useAuth`. Their guide is the one `@ic-reactor/core` ships.
+
+Applies to `@ic-reactor/react` 4.1.1.
+
+Read `node_modules/@ic-reactor/core/llms.txt`. It is the one guide for both
+packages: setup, the provider and `useAuth`, reads, writes, errors, values,
+and a complete React example, with the rules each call enforces.
+
+This package has no hook around `useQuery` or `useMutation`: call TanStack
+Query's own hooks with the options the client builds,
+`useQuery(client.queryOptions(...))` and
+`useMutation(client.mutationOptions(...))`. It never re-exports
+`@ic-reactor/core`: import each name from the package that defines it.
+
+## Keys follow the caller a render shows
+
+Call `useClient()` in the body of each component that builds keys or read
+options, on every render, and build them from what it returns there, never from
+a client held at module scope. It returns a view of the client for the caller
+the render shows: one object per caller, a new one after a sign-in, a switch of
+account or a sign-out, and the same one on every render while the caller stays.
+List it in the dependencies of what is built from it (`useMemo(() =>
+client.queryOptions(...), [client])`, an effect, a callback, as
+`react-hooks/exhaustive-deps` asks); React Compiler memoizes on it the same
+way, so what is memoized is built again for the new caller. Its `queryKey`,
+`queryOptions`, `caller()` and `authState()` are that caller's, and its
+`mutationOptions` send only as that caller: a write pressed before a switch
+reaches the render is refused (`kind` `"cancelled"`, `code` `"caller_changed"`,
+`mayHaveExecuted: false`) and sends nothing, so a click handler needs no check
+of its own. A re-send `client.resendOf()` offered is refused the same way but
+as `"outcome_unknown"` with `mayHaveExecuted: true`: the write it re-sends may
+have run, and stays offered. Their `mutationKey` ends with that caller. A handler that awaits
+`signIn()` and then calls `mutate` presses with the last committed render's
+options, and is refused if the signed-in render has not committed yet (one that
+suspends on the user's data): let the next render press, or make a direct call.
+A canister's direct calls sign as the caller current when they run. Canisters,
+`signIn`, `signOut` and the `QueryClient` are the client's own. It is never the
+provider's client object: compare two clients by their `queryClient`.
+
+Do not keep what it returns past the render: a view never moves on. Kept
+anywhere else (`useState(client)`, `useRef(client)`, a `useMemo` or
+`useCallback` with `[]`, a module variable), it stays the view of the caller
+it was taken for: the component shows that caller's data, a read it starts
+while someone else is signed in is cancelled, and a write through it is
+refused. Nothing warns about it. A nested `ReactorProvider` given it holds
+the client the view was made over. A component that calls `useClient()`
+renders again on each sign-in, switch of account and sign-out, and never for
+a change of status that leaves the caller as it is. On a server and while a
+page hydrates the caller is anonymous, as for `useAuth()`, so the hydrating
+render gets the anonymous caller's view: it finds what the server prefetched
+and dehydrated, matches the server's HTML and sends nothing. Right after
+hydrating, React renders the component again with the session's view, and
+each read loads the user's keys once: until the user's data arrives, a read
+shows its loading state, and a `useSuspenseQuery` read its boundary's
+fallback. A tab whose caller is anonymous anyway (no session, or one that
+expired or is signed in elsewhere) renders no `useClient()` component again,
+and a client built with `identity` is always returned as it is.
+
+A signed-in reload has three accepted costs:
+
+- A Suspense boundary still dehydrated below a component that calls
+  `useClient()` or `useAuth()` (its lazy code still loading, or its streamed
+  HTML not arrived yet) is rendered on the client when that component
+  moves on to the session: it shows its fallback, not the server's HTML, and
+  React 18 reports a recoverable error. Its data is still the user's. A
+  `useAuth()` component also moves on in a tab whose session expired or is
+  signed in elsewhere. Render such a boundary where no component that renders with the caller sits above
+  it, or pass it in as `children`, which a component's own update does not
+  render again.
+- A read the hydrating render built may still run once (a refetch of stale
+  data on mount, or a fetch from an effect) and is then cancelled before
+  anything is sent. A key that holds data keeps it as it was, and a fetch of
+  it resolves with that data. A key with none fails, with `kind`
+  `"cancelled"` and `code` `"caller_changed"`, until the anonymous caller is
+  current again: the hydrating render's own reads never show it, but a
+  listener of `client.queryClient.getQueryCache().subscribe()` (an
+  `"updated"` event whose `action.type` is `"error"`; the client takes no
+  `QueryCache` of yours), an effect that awaits the fetch and, for a
+  `useSuspenseQuery` read the server rendered without dehydrating its data,
+  React's `onRecoverableError` (as the reported error's `cause` on React 19)
+  see it, so ignore `kind` `"cancelled"` there.
+- Put a Suspense boundary above every component that reads with
+  `useSuspenseQuery`, on React 18 and 19 alike. The move to the session is a
+  synchronous update that such a read suspends until the user's data arrives:
+  with a boundary above, it shows the fallback, then the user's data, and the
+  rest of the page responds meanwhile. With none, React 18 refuses the update
+  ("A component suspended while responding to synchronous input") and
+  unmounts the root, so a signed-in reload renders nothing. React 19 keeps the
+  server's HTML on screen, but until the user's data arrives, however long the
+  read and its retries take, a click or any other update outside a transition
+  commits nothing, and neither does a transition that renders the reading
+  component again.

package/packages/react/package.json

@@ -0,0 +1,95 @@
+{
+  "name": "@ic-reactor/react",
+  "version": "4.1.1",
+  "description": "ic-reactor 4 React bindings: a provider that owns one client per tree, useClient and useAuth",
+  "main": "dist/index.js",
+  "module": "dist/index.js",
+  "types": "dist/index.d.ts",
+  "type": "module",
+  "engines": {
+    "node": ">=22.12.0"
+  },
+  "sideEffects": false,
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "import": "./dist/index.js",
+      "default": "./dist/index.js"
+    },
+    "./package.json": "./package.json"
+  },
+  "files": [
+    "dist",
+    "src",
+    "!src/**/*.test.*",
+    "!src/**/*.spec.*",
+    "!**/*.tsbuildinfo",
+    "README.md",
+    "llms.txt"
+  ],
+  "scripts": {
+    "build": "rm -rf dist tsconfig.tsbuildinfo && tsc",
+    "test": "vitest run",
+    "size": "size-limit",
+    "typecheck": "tsc --noEmit -p tsconfig.typecheck.json"
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/B3Pay/ic-reactor",
+    "directory": "packages/react"
+  },
+  "bugs": {
+    "url": "https://github.com/B3Pay/ic-reactor/issues"
+  },
+  "homepage": "https://ic-reactor.b3pay.net/v4/packages/react/",
+  "keywords": [
+    "internet-computer",
+    "icp",
+    "dfinity",
+    "react",
+    "hooks",
+    "web3",
+    "blockchain",
+    "canister",
+    "tanstack-query",
+    "ic-reactor",
+    "llms",
+    "ai-friendly"
+  ],
+  "author": "Behrad Deylami",
+  "license": "MIT",
+  "peerDependencies": {
+    "@ic-reactor/core": "workspace:*",
+    "@tanstack/react-query": "^5.90.2",
+    "react": ">=18.0.0"
+  },
+  "devDependencies": {
+    "@meantjs/schema": "0.6.0",
+    "@ic-reactor/core": "workspace:*",
+    "@size-limit/preset-small-lib": "^13.0.3",
+    "@tanstack/react-query": "^5.102.8",
+    "@testing-library/dom": "^10.4.1",
+    "@testing-library/react": "^16.3.3",
+    "@types/react": "^19.3.0",
+    "@types/react-dom": "^19.3.0",
+    "jsdom": "^30.0.1",
+    "react": "^19.3.0",
+    "react-dom": "^19.3.0",
+    "size-limit": "^13.0.3",
+    "vitest": "^5.0.0"
+  },
+  "size-limit": [
+    {
+      "name": "React bindings",
+      "path": "dist/index.js",
+      "limit": "1.51 KB",
+      "gzip": true,
+      "ignore": [
+        "react",
+        "react/jsx-runtime",
+        "@ic-reactor/core",
+        "@tanstack/react-query"
+      ]
+    }
+  ]
+}