vapor-chamber 1.0.0 → 1.2.0

package/README.md

@@ -145,9 +145,74 @@ Sub-path exports avoid pulling in optional modules:
 'vapor-chamber/transports'  → HTTP + WebSocket + SSE bridges only
 'vapor-chamber/directives'  → v-command Vue directive only
 'vapor-chamber/vite'        → Vite HMR plugin only
-'vapor-chamber/iife'        → IIFE bundle
+'vapor-chamber/fast-lane'     → minimal-allocation dispatcher for real-real-hot loops (game ticks, trading data, audio, scroll). Not a bus — see docs/performance.md.
+'vapor-chamber/observable'    → Symbol.observable interop — RxJS / xstream / callbag adapter
+'vapor-chamber/standard-schema'→ Standard Schema v1 validator plugin (Zod / Valibot / ArkType compatible)
+'vapor-chamber/alien-signals' → connector to use alien-signals as the underlying reactive primitive (non-Vue contexts)
+'vapor-chamber/iife'          → IIFE bundle (full)
+'vapor-chamber/iife-core'     → IIFE bundle (no Vapor custom-element, no Suspense paths)
+'vapor-chamber/iife-elements' → IIFE bundle (core + Vapor custom-element)
+```
+
+### IIFE / CDN variants
+
+Three `<script>`-tag drop-ins, sized for distinct deployment shapes. Pick by
+audience, not by feature checklist.
+
+| Variant   | Audience                                     | File                                  | Min   | Brotli | Gzip   |
+|-----------|----------------------------------------------|---------------------------------------|-------|--------|--------|
+| core      | Sprinkled JS on server-rendered pages (Blade, Rails, Django, .NET MVC, WordPress). You dispatch user actions to a backend over HTTP. | `vapor-chamber-core.iife.js`     | 23 KB | 6.1 KB | 6.8 KB |
+| elements  | Embeddable widgets (chat bubbles, checkout buttons, third-party drop-ins). You ship a `<vc-widget>` custom element. | `vapor-chamber-elements.iife.js` | 24 KB | 6.4 KB | 7.2 KB |
+| full      | SPAs that grew big enough to want everything (realtime, undo/redo, persistence, full Vapor surface). | `vapor-chamber.iife.js`              | 32 KB | 8.7 KB | 9.8 KB |
+
+**What's in each variant**
+
+| Surface                                                  | core | elements | full |
+|----------------------------------------------------------|:----:|:--------:|:----:|
+| Bus (`createCommandBus`, `createAsyncCommandBus`)        | ✅   | ✅       | ✅   |
+| `createApp()`, `connect()` one-liner                     | ✅   | ✅       | ✅   |
+| HTTP transport (`http`)                                  | ✅   | ✅       | ✅   |
+| Light plugins (logger, validator, debounce, throttle, retry, authGuard) | ✅   | ✅       | ✅   |
+| `defineVaporCustomElement`, `defineWidget()`             | ❌   | ✅       | ✅   |
+| WebSocket / SSE (`ws`, `sse`)                            | ❌   | ❌       | ✅   |
+| Heavy plugins (persist, sync, history, optimistic)       | ❌   | ❌       | ✅   |
+| `mount()`                                                | ❌   | ❌       | ✅   |
+| Full Vapor (`defineVaporComponent`, async/Suspense)      | ❌   | ❌       | ✅   |
+
+**Examples**
+
+```html
+<!-- core: dispatch over HTTP, with CSRF auto-wired -->
+<script src=".../vapor-chamber-core.iife.min.js"></script>
+<script>
+  const { dispatch } = VaporChamber.connect({ endpoint: '/api/vc' });
+  document.getElementById('add').addEventListener('click',
+    () => dispatch('cartAdd', { id: 42 }));
+</script>
 ```
 
+```html
+<!-- elements: register a custom-element widget in one call -->
+<script src=".../vapor-chamber-elements.iife.min.js"></script>
+<script>
+  VaporChamber.defineWidget('vc-cart', {
+    props: { sku: String },
+    setup(props) { return () => h('span', `SKU ${props.sku}`); }
+  });
+</script>
+<vc-cart sku="ABC-123"></vc-cart>
+```
+
+(Sizes measured against v1.2.0; min = `*.iife.min.js`. Brotli @ q=11, gzip @ -9.
+Modern CDNs serve brotli to every supported browser, so brotli is the number
+that hits the wire.) The build is driven by `scripts/build.mjs` (Vite programmatic
+API) — single source, multiple outputs.
+
+> **Variant contents are not under semver before v2.0.** While Vue 3.6 is in
+> beta, the lib reserves the right to move APIs between IIFE variants. ESM
+> consumers (the `vapor-chamber` main entry) get the full surface and are
+> unaffected. See [ROADMAP.md](./ROADMAP.md).
+
 ---
 
 ## Install
@@ -156,7 +221,27 @@ Sub-path exports avoid pulling in optional modules:
 npm install vapor-chamber
 ```
 
-**Requirements:** Node.js ≥20.19.0 | Vue ≥3.5.0 (optional peer dep) | Vite 7/8 compatible
+**Requirements:** Node.js ≥20.19.0 | Vue ≥3.5.0 (composables) or ≥3.6.0-beta.11 (full Vapor) — optional peer dep | Vite ≥7.0.0 + `@vitejs/plugin-vue` ≥5.0.0 (only required for the `vapor-chamber/vite` HMR plugin and Vapor SFC support)
+
+> **Beta tracking:** this lib follows Vue 3.6 while it is in beta. The Vapor
+> wrappers and the `useVaporCommand` / `useCommand` split are transitional
+> surfaces that will realign once Vue 3.6 ships stable. See [ROADMAP.md](./ROADMAP.md)
+> for what is stable today, what is transitional, and the v1.3 / v2 plan.
+>
+> **Performance & tuning:** see [docs/performance.md](./docs/performance.md)
+> for what's optimized by default, the consumer-facing tuning knobs
+> (`persist({ coalesce: true })`, `configureUid`, `configureSignal`), variant
+> selection guide, and a benchmark snapshot.
+>
+> **Laravel integration:** see [docs/integrations/laravel.md](./docs/integrations/laravel.md)
+> for the full backend deliverables list (route, controller, action classes,
+> CSRF flows, Sanctum, Inertia coexistence, Filament panels, Reverb
+> realtime, queued commands). Runnable PHP companions live in
+> [examples/laravel-backend/](./examples/laravel-backend/).
+>
+> **API reference:** generate locally with `npm run docs` (TypeDoc → `docs/api/`).
+> The generated site is `.gitignore`d so it stays fresh per release. Hosting it
+> publicly (e.g. via GitHub Pages or Netlify) is on the v1.3 ROADMAP.
 
 ## Quick Start
 
@@ -821,9 +906,9 @@ Dispatch multiple commands as a unit. Stops on the first failure by default:
 
 ```typescript
 const result = bus.dispatchBatch([
-  { action: 'cartAdd',        target: cart, payload: item },
-  { action: 'totalsUpdate',   target: cart },
-  { action: 'analyticsTrack', target: session, payload: item },
+  { action: 'cartAdd',       target: cart, payload: item },
+  { action: 'totalsUpdate',  target: cart },
+  { action: 'telemetryLog',  target: session, payload: item },
 ]);
 
 if (result.ok) {
@@ -913,14 +998,16 @@ const { dispatch, loading, lastError } = useCommand();
 ### defineVaporCommand
 
 Zero-overhead dispatch for hot paths — no reactive `loading`/`lastError` signals created.
-Ideal for GA4 tracking, scroll events, debounced search, fire-and-forget patterns:
+Ideal for fire-and-forget patterns: telemetry events, scroll-position sampling,
+debounced search, autosave — anywhere reactive loading state would be wasted overhead:
 
 ```vue
 <script setup vapor>
 import { defineVaporCommand } from 'vapor-chamber';
 
-const { dispatch } = defineVaporCommand('analyticsTrack', (cmd) => {
-  gtag('event', cmd.target.event, cmd.target.params);
+const { dispatch } = defineVaporCommand('telemetryEvent', (cmd) => {
+  // forward to whatever metrics / analytics SDK you use
+  sendMetric(cmd.target.name, cmd.target.params);
 });
 
 // Fire-and-forget — no reactive overhead in the alien-signals graph
@@ -1245,7 +1332,8 @@ See the [`examples/`](./examples) folder for complete, runnable examples:
 
 | Composable | Description |
 |------------|-------------|
-| `useCommand()` | Dispatch with reactive loading/error state |
+| `useCommand()` | Dispatch with reactive loading/error state (per-call signals) |
+| `useSharedCommandState(options?)` | Aggregate `isAnyLoading` + `errors` ring buffer, **shared** across every subscriber on the same bus. Use for toolbars, status bars, global spinners. Saves ~2 signal nodes per subscribing component. |
 | `useVaporCommand()` | Vapor-safe composable with dispatch, register, on, loading/error, auto-cleanup |
 | `defineVaporCommand(action, handler, options?)` | Zero-overhead dispatch for hot paths |
 | `useCommandState(initial, handlers)` | State managed by commands |

package/ROADMAP.md

@@ -0,0 +1,233 @@
+# Roadmap
+
+This project tracks Vue 3.6 while it is in beta. That has direct consequences
+for what's stable, what's transitional, and what will change once Vue 3.6
+ships stable. This file is the source of truth for that distinction.
+
+Last reviewed against **Vue 3.6.0-beta.11** (released 2026-05-07).
+
+---
+
+## Current posture: beta territory
+
+- **Peer dependency:** `vue: ">=3.5.0 || >=3.6.0-beta.11"`. The lib supports
+  Vue 3.5 (composables only) and Vue 3.6 betas (full Vapor surface).
+- **Vapor APIs are still moving.** `defineVaporCustomElement`, `defineVaporComponent`,
+  `defineVaporAsyncComponent` are stable in shape but their underlying behavior
+  has shifted between beta.10 and beta.11 (generics inference, emits/attrs split,
+  custom-element fallback in shadowRoot:false trees). The lib's wrappers are
+  pass-through, so consumers inherit each beta's improvements without code
+  changes — but the wrappers themselves exist precisely because the API is
+  not yet final.
+- **The lib's value during beta** is graceful degradation (`null` returns when
+  Vue's API is absent or not yet present), version probing (`isVaporAvailable`),
+  and a stable surface for consumers to code against while Vue itself iterates.
+
+## What is stable, regardless of Vue's beta cycle
+
+These layers are framework-agnostic and will not change shape across
+Vue 3.6 stable:
+
+- **Command bus** — `createCommandBus`, `createAsyncCommandBus`, plugins,
+  hooks, before-hooks, wildcard listeners, request/response, batch, query,
+  emit, meta, BusError, introspection.
+- **Transports** — HTTP, WebSocket, SSE bridges. Independent of Vue.
+- **Plugins** — logger, validator, history, debounce, throttle, authGuard,
+  optimistic, retry, persist, sync, cache, circuitBreaker, rateLimit, metrics.
+- **Schema / LLM layer** — bus → tool-call adapters for Anthropic / OpenAI.
+- **Form bus** — reactive form state with async validation.
+- **HTTP client** — fetch wrapper with CSRF, interceptors, dedup.
+- **Testing utilities** — createTestBus, snapshot, time-travel.
+- **`defineVaporCommand`** — the zero-overhead command dispatch primitive
+  has no Vue equivalent and stays.
+- **IIFE distribution** — three sized variants (core / elements / full)
+  matching Vue's tree-shake axes. Stable shape.
+
+## What is transitional and will realign post-3.6-stable
+
+Everything below exists primarily to bridge the 3.5→3.6 gap. None will be
+removed silently — each gets a deprecation cycle with a working escape hatch.
+
+### `useVaporCommand` and `useCommand` will converge
+
+The split exists because pre-3.6, `getCurrentInstance()`-based cleanup fails
+in Vapor components. By Vue 3.6 stable, `onScopeDispose` works in every
+component context, so `useCommand` can be Vapor-safe on its own.
+
+**Plan (v1.3 or v2):** Fold `useVaporCommand` into `useCommand`. Single
+composable, `onScopeDispose`-only cleanup. `useVaporCommand` becomes a
+deprecated re-export of `useCommand` for one minor cycle, then removed.
+
+**Removes:** ~60 lines of duplicated logic, plus the "which one do I use?"
+question from the docs.
+
+### Thin Vapor wrappers will become opt-in via build flag
+
+`defineVaporComponent`, `defineVaporCustomElement`, `defineVaporAsyncComponent`,
+and `createVaporChamberApp` exist to provide a `null`-returning safety surface
+when Vue's API is not present. After Vue 3.6 stable, that null path is dead
+code for any consumer who has Vue ≥ 3.6 in their dependency tree.
+
+**Plan (v1.3 cutover):** Ship two flavors from one source via Vite build flag
++ `package.json` conditional exports.
+
+```
+src/wrapper.ts:
+  const HAS_NATIVE_VAPOR = /* #__PURE__ */ __VAPOR_NATIVE__;
+  export function defineVaporComponent(options) {
+    if (HAS_NATIVE_VAPOR) return options;          // DCE drops this branch
+    const fn = getDefineVaporComponentFn();
+    if (!fn) return null;
+    return fn(options);
+  }
+
+scripts/build.mjs:
+  build with __VAPOR_NATIVE__ = false  → dist/index.js          (legacy/beta)
+  build with __VAPOR_NATIVE__ = true   → dist/index.modern.js   (3.6 stable+)
+
+package.json#exports:
+  ".": {
+    "vue36": "./dist/index.modern.js",
+    "import": "./dist/index.js",
+    "types": "./dist/index.d.ts"
+  }
+```
+
+Consumers on Vue 3.6 stable add `vue36` to their Vite `resolve.conditions`
+once and the wrapper bodies + entire feature-detection registry in
+`chamber.ts` (`getDefineVaporComponentFn`, `_defineVaporCustomElementFn`, etc.)
+are tree-shaken to zero.
+
+**No source split, no API breakage.** The wrapper functions still exist by
+name in both flavors — the modern flavor just inlines them as identity calls.
+
+### Runtime feature-detection registry will shrink
+
+`chamber.ts` currently maintains a registry of probed Vue functions
+(`_defineVaporCustomElementFn`, `_vueOnScopeDispose`, `_vueOnUnmounted`,
+`_vueOnActivated`, `_vueOnDeactivated`, etc.). Each entry exists because the
+specific Vue version may or may not have it.
+
+**Plan (post-3.6-stable):** When `vue36` build flavor is active, the registry
+collapses to a direct `import { onScopeDispose, ... } from 'vue'`. No more
+property probing, no more null guards. Still tree-shaken when unused.
+
+### `createVaporChamberApp` will become a soft-deprecated convenience
+
+It throws nicer than `createVaporApp` would when Vue Vapor is absent. Useful
+during beta for discoverability. Post-stable, point users at `import { createVaporApp } from 'vue'` directly.
+
+**Plan:** JSDoc `@deprecated` in v1.3, working through v2.
+
+## Variant contents are not under semver before v2.0
+
+The IIFE variants (`core`, `elements`, `full`) are split along **audience /
+deployment-shape** axes — sprinkled JS, embeddable widgets, kitchen-sink SPAs.
+While Vue 3.6 is in beta, the lib reserves the right to move APIs between
+variants. Concretely:
+
+- An API that lives in `core` today may move to `full` in a later v1.x release
+  if usage data or audience clarification suggests it doesn't fit the variant's
+  identity. Example: WebSocket / SSE bridges moved out of `core` in v1.2.0
+  because realtime is a different deployment shape than sprinkled-JS.
+- A new API may appear in `core` that wasn't there before, if it's idiomatic
+  for the audience. Example: `connect()` was added in v1.2.0 as a one-liner
+  for the sprinkled-JS audience.
+- ESM consumers (the `vapor-chamber` main entry) are unaffected — the main
+  entry exposes the union of all variants and obeys strict semver.
+
+This contract relaxes at v2.0: once Vue 3.6 ships stable and consumer
+deployment patterns are observable, variant boundaries become semver-stable.
+Until then, treat IIFE variant *names* as stable but variant *contents* as
+beta-era refinement.
+
+If you pin to a specific variant's API surface, do so against `dist/` in your
+own infrastructure, not the public CDN. The full surface is always in `full`.
+
+## Two doorways: general bus and fast lane
+
+The lib ships **two dispatch paths** under the same package, with deliberately
+different shapes:
+
+- **`createCommandBus()` — general purpose.** Command envelope, CommandResult,
+  plugin chain, before/after hooks, listeners (exact + wildcard), schema,
+  batch with rollback, request/response, AbortController, persist/sync/retry,
+  HTTP/WS/SSE transports, Vapor wrappers. Ergonomics-first. Use for app-level
+  commands.
+- **`createFastLane()` (`vapor-chamber/fast-lane`) — real-real-hot path.**
+  Strips everything: no envelope, no result, no plugins, no hooks, no
+  wildcards, no abort. Just `compile(action, handler)` returning a
+  callable, plus `on`/`emit` for fan-out. Use for per-frame game ticks,
+  trading data feeds, audio buffer processing, scroll/mousemove sampling,
+  physics steps. ~36× faster than `bus.dispatch` (25,400 vs 700 ops/sec on
+  the 10k-dispatch bench).
+
+The two are not interchangeable. The fast lane is **not** a faster bus —
+it's a different tool for a different workload. Don't reach for it because
+it's faster; reach for it because you've measured the general bus as a
+bottleneck on a hot loop.
+
+See [docs/performance.md](./docs/performance.md) for the full positioning,
+benchmark numbers, and decision tree.
+
+## What is not on the roadmap
+
+- **Directives in Vapor.** The Vue team has consistently signaled directives
+  remain a VDOM-only feature. The lib's `createDirectivePlugin` will stay as
+  a VDOM helper; no Vapor-port effort planned. Directives are not in the
+  growth path.
+- **Forking Vue internals.** The lib intentionally wraps Vue's public API
+  and detects features at runtime. Bundling polyfills or forking compiler
+  output is out of scope.
+- **A full SFC-aware HMR replacement.** `vite-hmr.ts` will keep tracking
+  `@vitejs/plugin-vue` rather than re-implementing HMR.
+
+## Version targets
+
+| Version | Trigger                          | Headline                                                                 |
+|---------|----------------------------------|--------------------------------------------------------------------------|
+| v1.2.x  | Vue 3.6.0-beta.11+               | Beta-aligned: docs, build pipeline, IIFE split, regression tests, V8-aligned hot path, listener bucketing, persist coalescing |
+| v1.3.0  | First Vue 3.6 RC or stable       | Build-flag wrapper elimination; `vue36` conditional export; soft-deprecations begin; Rolldown migration if stable in Vite 8; `AbortController` extensions (request/respond, dispatchBatch, child signals, WS/SSE bridge propagation); protocol-aware `createEchoBridge` for Laravel Reverb / Echo (channels / private / presence) |
+| v2.0.0  | One minor cycle after 3.6 stable | Drop `useVaporCommand` (folded into `useCommand`); registry collapse; remove wrappers' null path |
+
+## Vite + plugin-vue alignment
+
+The library is currently aligned to **Vite ≥ 7.0.0** and **@vitejs/plugin-vue
+≥ 5.0.0**. Both are declared as optional peerDependencies — they only matter
+if a consumer uses the `vapor-chamber/vite` HMR plugin or compiles Vue SFCs
+that target Vapor mode.
+
+**Tracking forward:**
+
+- **Vite 8 + Rolldown.** Vite 8 (expected late 2026) is anticipated to ship
+  with Rolldown — a Rust-based Rollup successor — as the default bundler. The
+  build pipeline ([scripts/build.mjs](./scripts/build.mjs)) uses Vite's
+  programmatic `build()` API which is stable across Rolldown's migration; no
+  source changes are anticipated. We'll re-measure IIFE sizes after the swap
+  and update README numbers if they shift materially.
+- **plugin-vue 6.x.** Expected alongside Vue 3.6 stable. Will be tested
+  before bumping the peerDep range.
+- **Lightning CSS.** Vite's CSS pipeline doesn't affect vapor-chamber (the
+  lib emits no CSS), so no action needed.
+
+Versioning is semver-strict: the v2 changes only happen behind a major bump
+because the deprecations land first in v1.3 with at least one release cycle
+of warnings.
+
+## How to read this file
+
+If you're a consumer choosing between APIs in this lib:
+
+- **Stable today, stable in v2:** the "stable, regardless of Vue's beta cycle"
+  list above. Use freely.
+- **Working today, will be reshaped in v2:** the "transitional" list. Use, but
+  expect a deprecation cycle. The escape hatch will always exist for one minor
+  before removal.
+- **Avoid:** anything not listed above is internal. The `_*` prefixed and
+  `getXxxFn()` exports in `chamber.ts` are explicitly internal.
+
+If you're contributing: the build-flag wrapper-elimination work is the single
+biggest pending change. It's blocked on Vue 3.6 RC — no need to land it in beta.
+
+For performance characteristics, optimization philosophy, and tuning options
+see [docs/performance.md](./docs/performance.md).

package/dist/alien-signals.d.ts

@@ -0,0 +1,80 @@
+/**
+ * vapor-chamber — alien-signals connector.
+ *
+ * Bridges [alien-signals](https://github.com/stackblitz/alien-signals)'
+ * function-call API to vapor-chamber's `.value`-style `Signal` interface.
+ *
+ * ## Why this exists
+ *
+ * Vue 3.6's `ref()` is itself a port of alien-signals' algorithm
+ * ([vuejs/core#12349](https://github.com/vuejs/core/pull/12349)) — so when
+ * vapor-chamber auto-detects `vue.ref`, you're already on alien-signals
+ * under the hood. This connector is for **non-Vue consumers** who want
+ * the same fine-grained reactivity:
+ *
+ *   • SSR / Node services that don't import Vue
+ *   • Web Workers / service workers
+ *   • Embedded widgets shipping without Vue
+ *   • Any context where you want push-pull reactivity but Vue's full
+ *     runtime is overkill
+ *
+ * ## No runtime dep
+ *
+ * The connector takes alien-signals' `signal` function as an argument
+ * rather than importing it. Consumers install `alien-signals` themselves;
+ * vapor-chamber stays Vue-agnostic on the runtime side.
+ *
+ * @example
+ * import { signal as alienSignal } from 'alien-signals';
+ * import { configureAlienSignals } from 'vapor-chamber/alien-signals';
+ *
+ * configureAlienSignals(alienSignal);
+ *
+ * // From this point on, every vapor-chamber signal() call wraps an
+ * // alien-signal under the hood. useCommand, useSharedCommandState, the
+ * // FormBus signals — all backed by alien-signals' propagation algorithm.
+ */
+import { type CreateSignal } from './signal';
+/**
+ * The shape alien-signals' `signal` function exposes. Both reading
+ * (`s()`) and writing (`s(value)`) go through the same callable.
+ *
+ * Defined locally so the connector has no `import 'alien-signals'`
+ * dependency — consumers feed in the function from their own install.
+ */
+export type AlienSignalFn = <T>(initial?: T) => {
+    /** Read */ (): T;
+    /** Write */ (next: T): T;
+};
+/**
+ * Build a `CreateSignal` adapter from alien-signals' `signal` function.
+ * The returned function is what `configureSignal()` expects — it produces
+ * vapor-chamber-style `{ value }` objects backed by an alien-signal.
+ *
+ * Use this when you want manual control. For the typical case, prefer
+ * {@link configureAlienSignals} which installs the adapter directly.
+ *
+ * @example
+ * import { signal as alienSignal } from 'alien-signals';
+ * import { configureSignal } from 'vapor-chamber';
+ * import { alienSignalAdapter } from 'vapor-chamber/alien-signals';
+ *
+ * configureSignal(alienSignalAdapter(alienSignal));
+ */
+export declare function alienSignalAdapter(alienSignal: AlienSignalFn): CreateSignal;
+/**
+ * Install alien-signals as the underlying reactive primitive for every
+ * vapor-chamber signal. Call once at app startup, before any `signal()`,
+ * `useCommand()`, `useSharedCommandState()`, or `createFormBus()` call.
+ *
+ * @example
+ * import { signal as alienSignal } from 'alien-signals';
+ * import { configureAlienSignals } from 'vapor-chamber/alien-signals';
+ *
+ * configureAlienSignals(alienSignal);
+ *
+ * // Now use vapor-chamber composables / signal() normally — they're
+ * // backed by alien-signals' push-pull propagation.
+ */
+export declare function configureAlienSignals(alienSignal: AlienSignalFn): void;
+//# sourceMappingURL=alien-signals.d.ts.map

package/dist/alien-signals.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"alien-signals.d.ts","sourceRoot":"","sources":["../src/alien-signals.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmCG;AAEH,OAAO,EAAgC,KAAK,YAAY,EAAE,MAAM,UAAU,CAAC;AAE3E;;;;;;GAMG;AACH,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,EAAE,OAAO,CAAC,EAAE,CAAC,KAAK;IAC9C,WAAW,CAAC,IAAI,CAAC,CAAC;IAClB,YAAY,CAAC,CAAC,IAAI,EAAE,CAAC,GAAG,CAAC,CAAC;CAC3B,CAAC;AAEF;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,kBAAkB,CAAC,WAAW,EAAE,aAAa,GAAG,YAAY,CAQ3E;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,qBAAqB,CAAC,WAAW,EAAE,aAAa,GAAG,IAAI,CAEtE"}

package/dist/alien-signals.js

@@ -0,0 +1,22 @@
+import { c as configureSignal } from "./signal-DUZrcb-E.js";
+function alienSignalAdapter(alienSignal) {
+  return (initial) => {
+    const s = alienSignal(initial);
+    return {
+      get value() {
+        return s();
+      },
+      set value(next) {
+        s(next);
+      }
+    };
+  };
+}
+function configureAlienSignals(alienSignal) {
+  configureSignal(alienSignalAdapter(alienSignal));
+}
+export {
+  alienSignalAdapter,
+  configureAlienSignals
+};
+//# sourceMappingURL=alien-signals.js.map

package/dist/alien-signals.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"alien-signals.js","sources":["../src/alien-signals.ts"],"sourcesContent":["/**\n * vapor-chamber — alien-signals connector.\n *\n * Bridges [alien-signals](https://github.com/stackblitz/alien-signals)'\n * function-call API to vapor-chamber's `.value`-style `Signal` interface.\n *\n * ## Why this exists\n *\n * Vue 3.6's `ref()` is itself a port of alien-signals' algorithm\n * ([vuejs/core#12349](https://github.com/vuejs/core/pull/12349)) — so when\n * vapor-chamber auto-detects `vue.ref`, you're already on alien-signals\n * under the hood. This connector is for **non-Vue consumers** who want\n * the same fine-grained reactivity:\n *\n *   • SSR / Node services that don't import Vue\n *   • Web Workers / service workers\n *   • Embedded widgets shipping without Vue\n *   • Any context where you want push-pull reactivity but Vue's full\n *     runtime is overkill\n *\n * ## No runtime dep\n *\n * The connector takes alien-signals' `signal` function as an argument\n * rather than importing it. Consumers install `alien-signals` themselves;\n * vapor-chamber stays Vue-agnostic on the runtime side.\n *\n * @example\n * import { signal as alienSignal } from 'alien-signals';\n * import { configureAlienSignals } from 'vapor-chamber/alien-signals';\n *\n * configureAlienSignals(alienSignal);\n *\n * // From this point on, every vapor-chamber signal() call wraps an\n * // alien-signal under the hood. useCommand, useSharedCommandState, the\n * // FormBus signals — all backed by alien-signals' propagation algorithm.\n */\n\nimport { configureSignal, type Signal, type CreateSignal } from './signal';\n\n/**\n * The shape alien-signals' `signal` function exposes. Both reading\n * (`s()`) and writing (`s(value)`) go through the same callable.\n *\n * Defined locally so the connector has no `import 'alien-signals'`\n * dependency — consumers feed in the function from their own install.\n */\nexport type AlienSignalFn = <T>(initial?: T) => {\n  /** Read */ (): T;\n  /** Write */ (next: T): T;\n};\n\n/**\n * Build a `CreateSignal` adapter from alien-signals' `signal` function.\n * The returned function is what `configureSignal()` expects — it produces\n * vapor-chamber-style `{ value }` objects backed by an alien-signal.\n *\n * Use this when you want manual control. For the typical case, prefer\n * {@link configureAlienSignals} which installs the adapter directly.\n *\n * @example\n * import { signal as alienSignal } from 'alien-signals';\n * import { configureSignal } from 'vapor-chamber';\n * import { alienSignalAdapter } from 'vapor-chamber/alien-signals';\n *\n * configureSignal(alienSignalAdapter(alienSignal));\n */\nexport function alienSignalAdapter(alienSignal: AlienSignalFn): CreateSignal {\n  return <T>(initial: T): Signal<T> => {\n    const s = alienSignal<T>(initial);\n    return {\n      get value(): T { return s() as T; },\n      set value(next: T) { s(next); },\n    };\n  };\n}\n\n/**\n * Install alien-signals as the underlying reactive primitive for every\n * vapor-chamber signal. Call once at app startup, before any `signal()`,\n * `useCommand()`, `useSharedCommandState()`, or `createFormBus()` call.\n *\n * @example\n * import { signal as alienSignal } from 'alien-signals';\n * import { configureAlienSignals } from 'vapor-chamber/alien-signals';\n *\n * configureAlienSignals(alienSignal);\n *\n * // Now use vapor-chamber composables / signal() normally — they're\n * // backed by alien-signals' push-pull propagation.\n */\nexport function configureAlienSignals(alienSignal: AlienSignalFn): void {\n  configureSignal(alienSignalAdapter(alienSignal));\n}\n"],"names":[],"mappings":";AAkEO,SAAS,mBAAmB,aAA0C;AAC3E,SAAO,CAAI,YAA0B;AACnC,UAAM,IAAI,YAAe,OAAO;AAChC,WAAO;AAAA,MACL,IAAI,QAAW;AAAE,eAAO,EAAA;AAAA,MAAU;AAAA,MAClC,IAAI,MAAM,MAAS;AAAE,UAAE,IAAI;AAAA,MAAG;AAAA,IAAA;AAAA,EAElC;AACF;AAgBO,SAAS,sBAAsB,aAAkC;AACtE,kBAAgB,mBAAmB,WAAW,CAAC;AACjD;"}