@vellumai/plugin-api 0.10.11 → 0.10.12-dev.202607242326.75b9ec6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (4) hide show
  1. package/app.d.ts +84 -0
  2. package/index.d.ts +1853 -3384
  3. package/index.js +3 -0
  4. package/package.json +6 -2
package/app.d.ts ADDED
@@ -0,0 +1,84 @@
1
+ /**
2
+ * Ambient global types for the **app-side** Vellum bridge — `window.vellum`.
3
+ *
4
+ * A Vellum plugin app runs inside a sandboxed iframe, and the host injects a
5
+ * `window.vellum` object into it at load time (see the assistant's
6
+ * `sandbox-bridge` runtime). This file is the type-only counterpart to that
7
+ * injection: it teaches TypeScript the shape of `window.vellum` so an app can
8
+ * call `window.vellum.fetch(...)` without hand-declaring the global in every
9
+ * project.
10
+ *
11
+ * Only `fetch` is typed for now — the surface the vast majority of apps
12
+ * actually use. Other injected members are intentionally left undeclared until
13
+ * there's a concrete need.
14
+ *
15
+ * A plugin app that depends on `@vellumai/plugin-api` pulls this in via a
16
+ * one-line reference (recommended — no runtime import, which apps can't rely
17
+ * on inside the sandbox):
18
+ *
19
+ * ```ts
20
+ * /// <reference types="@vellumai/plugin-api/app" />
21
+ * ```
22
+ *
23
+ * or by adding `"@vellumai/plugin-api/app"` to `compilerOptions.types` in
24
+ * `tsconfig.json`. Either way the app no longer needs its own `vellum.d.ts`.
25
+ *
26
+ * The named types below are also exported, so app code that wants to annotate
27
+ * a variable can `import type { VellumAppBridge } from "@vellumai/plugin-api/app"`.
28
+ */
29
+
30
+ /**
31
+ * Request init accepted by {@link VellumAppBridge.fetch}. A subset of the DOM
32
+ * `RequestInit`: the bridge serializes the request across `postMessage`, so
33
+ * `headers` must be a plain object and `body` a string (not a `Headers`
34
+ * instance, `FormData`, or a stream).
35
+ */
36
+ export interface VellumAppFetchInit {
37
+ /** HTTP method. Defaults to `"GET"`. */
38
+ method?: string;
39
+ /** Request headers as a plain object. */
40
+ headers?: Record<string, string>;
41
+ /** Request body. Already-serialized string payloads only. */
42
+ body?: string | null;
43
+ }
44
+
45
+ /**
46
+ * Response returned by {@link VellumAppBridge.fetch}. A `fetch`-like subset,
47
+ * not a full DOM `Response`: the body is delivered as text across the bridge,
48
+ * so only `json()` and `text()` are available (no `blob()`, `body`, etc.).
49
+ */
50
+ export interface VellumAppFetchResponse {
51
+ /** True when `status` is in the 2xx range. */
52
+ ok: boolean;
53
+ status: number;
54
+ statusText: string;
55
+ /** Response headers as a plain object. */
56
+ headers: Record<string, string>;
57
+ /** Parse the response body as JSON. */
58
+ json(): Promise<unknown>;
59
+ /** Read the response body as text. */
60
+ text(): Promise<string>;
61
+ }
62
+
63
+ /**
64
+ * The `window.vellum` bridge the host injects into a plugin app's sandboxed
65
+ * iframe. Mirrors the runtime built by the assistant's `sandbox-bridge`.
66
+ */
67
+ export interface VellumAppBridge {
68
+ /**
69
+ * Authenticated `fetch` to the app's own custom routes under `/v1/x/` (a
70
+ * leading `/x/` is accepted and normalized). Proxied through the host so the
71
+ * assistant's session/auth is attached — use this instead of the bare
72
+ * global `fetch`, which fails from the sandboxed origin.
73
+ */
74
+ fetch(
75
+ path: string,
76
+ options?: VellumAppFetchInit,
77
+ ): Promise<VellumAppFetchResponse>;
78
+ }
79
+
80
+ declare global {
81
+ interface Window {
82
+ vellum: VellumAppBridge;
83
+ }
84
+ }