@reticlehq/vite-plugin 2.10.0 → 2.12.0

package/dist/index.cjs

@@ -36,7 +36,6 @@ __export(index_exports, {
   RETICLE_DEV_MODULE_CANDIDATES: () => RETICLE_DEV_MODULE_CANDIDATES,
   RETICLE_TOKEN_GLOBAL: () => RETICLE_TOKEN_GLOBAL,
   RETICLE_VITE_PLUGIN_NAME: () => RETICLE_VITE_PLUGIN_NAME,
-  cjsDepIncludes: () => cjsDepIncludes,
   connectChurnWarning: () => connectChurnWarning,
   connectModuleSource: () => connectModuleSource,
   findDevModule: () => findDevModule,
@@ -86,7 +85,8 @@ var import_babel_plugin = __toESM(require("@reticlehq/babel-plugin"), 1);
 // ../core/dist/constants.js
 var RETICLE_DEFAULT_PORT = 4400;
 var RETICLE_WS_PATH = "/reticle";
-function bridgeWsUrl(port = RETICLE_DEFAULT_PORT, host = "localhost") {
+var RETICLE_CLIENT_HOST = "localhost";
+function bridgeWsUrl(port = RETICLE_DEFAULT_PORT, host = RETICLE_CLIENT_HOST) {
   return `ws://${host}:${String(port)}${RETICLE_WS_PATH}`;
 }
 var ReticleEnv = {
@@ -223,6 +223,8 @@ var ReticleDir = {
    * questions about the product; this answers the user's question about their own work.
    */
   IMPACT_FILE: "impact.json",
+  /** what changes were SUPPOSED to make true —.reticle/intent.json (git-checked, reviewed) */
+  INTENT_FILE: "intent.json",
   /** opt-in pixel baselines —.reticle/visual/<name>.png + <name>.diff.png. */
   VISUAL_SUBDIR: "visual",
   /** verification-run artifacts —.reticle/runs/<runId>.json (the OEM/CI-consumable verdict). */
@@ -285,6 +287,12 @@ var EventType = {
   STORAGE_CHANGE: "storage.change",
   /** page-level visibility/focus health (distinct from element-level VISIBLE_*). */
   PAGE_HEALTH: "page.health",
+  /**
+   * synthetic: the page called window.open, so the consequence of what was just clicked may live in
+   * another browsing context this one cannot observe (an OAuth popup is the archetype).
+   * `data: { href }` — the URL the page asked to open, when it named one.
+   */
+  CONTEXT_OPENED: "context.opened",
   /** aggregated React commits over a throttle window (dev builds) — `data: { commits }`. Commit storms /
    * wasted re-renders show up here without a per-render flood. */
   RENDER_COMMIT: "render.commit",
@@ -4604,7 +4612,8 @@ var import_node_module2 = require("node:module");
 var RETICLE_PACKAGE = "@reticlehq/react";
 var MANIFEST_SEARCH_DEPTH = 5;
 function requireFromApp(from) {
-  return (0, import_node_module2.createRequire)((0, import_node_path5.join)(from, "package.json"));
+  const absoluteFrom = (0, import_node_path5.isAbsolute)(from) ? from : (0, import_node_path5.resolve)(process.cwd(), from);
+  return (0, import_node_module2.createRequire)((0, import_node_path5.join)(absoluteFrom, "package.json"));
 }
 function packageDirOf(specifier, from) {
   try {
@@ -4758,13 +4767,6 @@ function stamp(code, id) {
     map: out.map === void 0 || null === out.map ? null : JSON.stringify(out.map)
   };
 }
-var SDK_CJS_DEPS = {
-  TESTING_LIBRARY: "@testing-library/dom",
-  ARIA_QUERY: "aria-query"
-};
-function cjsDepIncludes(appRoot, canResolve = (dep) => null !== resolvableChain([dep], appRoot)) {
-  return [SDK_CJS_DEPS.TESTING_LIBRARY, SDK_CJS_DEPS.ARIA_QUERY].filter(canResolve);
-}
 function readPairingToken() {
   const override = process.env[ReticleEnv.PAIRING_TOKEN_DIR];
   const dir = override !== void 0 && override.length > 0 ? override : (0, import_node_path6.join)((0, import_node_os2.homedir)(), ReticleDir.ROOT);
@@ -4812,6 +4814,20 @@ function findDevModule(root, exists) {
   return null;
 }
 function installedSdk(appRoot, canResolve = (dep) => null !== resolvableChain([dep], appRoot)) {
+  try {
+    const pkgPath = (0, import_node_path6.join)(appRoot, "package.json");
+    if ((0, import_node_fs5.existsSync)(pkgPath)) {
+      const pkg = JSON.parse((0, import_node_fs5.readFileSync)(pkgPath, "utf8"));
+      const deps = { ...pkg.dependencies ?? {}, ...pkg.devDependencies ?? {} };
+      if (deps[RETICLE_SENSOR] !== void 0 && deps[RETICLE_PACKAGE2] === void 0) {
+        return { specifier: RETICLE_SENSOR, usesInstall: false };
+      }
+      if (deps[RETICLE_PACKAGE2] !== void 0) {
+        return { specifier: RETICLE_PACKAGE2, usesInstall: true };
+      }
+    }
+  } catch {
+  }
   if (canResolve(RETICLE_PACKAGE2)) return { specifier: RETICLE_PACKAGE2, usesInstall: true };
   if (canResolve(RETICLE_SENSOR)) return { specifier: RETICLE_SENSOR, usesInstall: false };
   return { specifier: RETICLE_PACKAGE2, usesInstall: true };
@@ -4821,9 +4837,11 @@ function connectModuleSource(options, devModule = null) {
   const sdk = installedSdk(options.root ?? process.cwd());
   const named = sdk.usesInstall ? "reticle, install" : "reticle";
   const call = sdk.usesInstall ? "install();\n" : "";
+  const hot = `if (import.meta.hot) reticle.observeHotUpdates(import.meta.hot);
+`;
   const base = `import { ${named} } from '${sdk.specifier}';
 ${call}reticle.connect(${args});
-`;
+${hot}`;
   return null === devModule ? base : `${base}import('${devModule}');
 `;
 }
@@ -4869,21 +4887,11 @@ function reticle(options = {}) {
     ...true === options.desktop ? {} : { apply: "serve" },
     enforce: "pre",
     /**
-     * Declare the SDK's CJS runtime deps so Vite pre-bundles them.
-     *
-     * `@testing-library/dom` is what `by: role` matching runs on, and it pulls CJS `aria-query`. When
-     * the SDK resolves from OUTSIDE the app's root — a linked package, a pnpm workspace, `npm link`,
-     * a monorepo alias — Vite skips pre-bundling and the named import dies with "does not provide an
-     * export named 'elementRoles'". That takes the WHOLE SDK down before connect() runs, so there is
-     * no session, no Reticle-side error, and only a console SyntaxError naming a package the
-     * developer has never heard of. Measured on the react-admin demo with the SDK aliased to a local
-     * checkout: zero sessions, and it looked like the app was failing to render.
+     * Declare the SDK itself and the optimizer cache fingerprint.
      *
-     * Declaring them is free when Vite would have found them anyway — but only when they are
-     * actually installed. Naming a package that is not there makes Vite log `Failed to resolve
-     * dependency: …, present in optimizeDeps.include` on every boot, which is a scary line pointing
-     * at Reticle for a problem that does not exist. SvelteKit apps hit exactly that: nothing in that
-     * tree depends on @testing-library/dom.
+     * The browser SDK used to need extra CJS query-engine deps here. It no longer imports that
+     * second accessibility engine, so keeping those names would make Vite pre-bundle packages the
+     * app may not have and blame Reticle for a false `Failed to resolve dependency` warning.
      */
     config(config) {
       const appRoot = config.root ?? process.cwd();
@@ -4965,10 +4973,7 @@ function reticle(options = {}) {
             // Whichever SDK this app actually has: naming `@reticlehq/react` in a Vue app that was
             // given the sensor produces the exact boot warning the note below is about, for a
             // package that is correctly absent.
-            installedSdk(appRoot).specifier,
-            // Only in a form that resolves — see above; a name Vite cannot resolve produces a boot
-            // warning that blames Reticle, and a forced re-optimization on every cold start.
-            ...cjsDepIncludes(appRoot)
+            installedSdk(appRoot).specifier
           ]
         }
       };
@@ -5082,7 +5087,6 @@ ${code}`;
   RETICLE_DEV_MODULE_CANDIDATES,
   RETICLE_TOKEN_GLOBAL,
   RETICLE_VITE_PLUGIN_NAME,
-  cjsDepIncludes,
   connectChurnWarning,
   connectModuleSource,
   findDevModule,

package/dist/index.d.cts

@@ -191,28 +191,11 @@ interface HtmlTag {
     injectTo: 'body' | 'head-prepend';
 }
 /**
- * Name each CJS dep ONLY in the bare form, and only when the app root can resolve it.
- *
- * This used to try three layouts and emit Vite's nested `a > b > c` form when a hoisted lookup
- * failed. The guard asked the wrong question: it tested NODE resolvability, walking the chain
- * segment by segment, and under pnpm that succeeds exactly where Vite fails. Measured on the
- * sveltekit fixture:
- *
- *   ['@testing-library/dom']                                           -> null
- *   ['@reticlehq/browser', '@testing-library/dom']                     -> null
- *   ['@reticlehq/react', '@reticlehq/browser', '@testing-library/dom'] -> emitted
- *
- * So we emitted the three-segment chain, Vite could not follow it, and the boot warning this
- * function exists to prevent appeared anyway — `Failed to resolve dependency: …, present in
- * optimizeDeps.include`, pointing at Reticle, naming a package the developer has never heard of,
- * and forcing a full re-optimization on every cold start. The comment stated the rule correctly and
- * the code broke it.
- *
- * Dropping the nested form loses nothing that matters: the SDK itself is still pre-bundled, and Vite
- * follows its imports when it does that, so these deps are handled as part of it. Naming them
- * separately was belt-and-braces for a locally-aliased SDK, where the bare form resolves anyway.
+ * Read the daemon's auto-provisioned pairing token (~/.reticle/pairing-token, or the
+ * RETICLE_PAIRING_TOKEN_DIR override) so the served app can present it. Node-side only — a browser
+ * sandbox can't read the file, which is exactly why a rogue localhost app can't forge it. Best-effort:
+ * undefined if the daemon hasn't started yet (the page reloads once it has). Exported for testing.
  */
-export declare function cjsDepIncludes(appRoot: string, canResolve?: (dep: string) => boolean): string[];
 export declare function readPairingToken(): string | undefined;
 /** The body of the connect module — real imports, resolved by Vite when the module is served. */
 /**

package/dist/index.d.ts

@@ -191,28 +191,11 @@ interface HtmlTag {
     injectTo: 'body' | 'head-prepend';
 }
 /**
- * Name each CJS dep ONLY in the bare form, and only when the app root can resolve it.
- *
- * This used to try three layouts and emit Vite's nested `a > b > c` form when a hoisted lookup
- * failed. The guard asked the wrong question: it tested NODE resolvability, walking the chain
- * segment by segment, and under pnpm that succeeds exactly where Vite fails. Measured on the
- * sveltekit fixture:
- *
- *   ['@testing-library/dom']                                           -> null
- *   ['@reticlehq/browser', '@testing-library/dom']                     -> null
- *   ['@reticlehq/react', '@reticlehq/browser', '@testing-library/dom'] -> emitted
- *
- * So we emitted the three-segment chain, Vite could not follow it, and the boot warning this
- * function exists to prevent appeared anyway — `Failed to resolve dependency: …, present in
- * optimizeDeps.include`, pointing at Reticle, naming a package the developer has never heard of,
- * and forcing a full re-optimization on every cold start. The comment stated the rule correctly and
- * the code broke it.
- *
- * Dropping the nested form loses nothing that matters: the SDK itself is still pre-bundled, and Vite
- * follows its imports when it does that, so these deps are handled as part of it. Naming them
- * separately was belt-and-braces for a locally-aliased SDK, where the bare form resolves anyway.
+ * Read the daemon's auto-provisioned pairing token (~/.reticle/pairing-token, or the
+ * RETICLE_PAIRING_TOKEN_DIR override) so the served app can present it. Node-side only — a browser
+ * sandbox can't read the file, which is exactly why a rogue localhost app can't forge it. Best-effort:
+ * undefined if the daemon hasn't started yet (the page reloads once it has). Exported for testing.
  */
-export declare function cjsDepIncludes(appRoot: string, canResolve?: (dep: string) => boolean): string[];
 export declare function readPairingToken(): string | undefined;
 /** The body of the connect module — real imports, resolved by Vite when the module is served. */
 /**

package/dist/index.js

@@ -1,4 +1,4 @@
-import { existsSync } from 'node:fs';
+import { existsSync, readFileSync } from 'node:fs';
 import { missingTokenWarning } from './missing-token.js';
 import { ensurePairingToken } from './ensure-token.js';
 import { homedir } from 'node:os';
@@ -150,43 +150,6 @@ function stamp(code, id) {
  * sandbox can't read the file, which is exactly why a rogue localhost app can't forge it. Best-effort:
  * undefined if the daemon hasn't started yet (the page reloads once it has). Exported for testing.
  */
-/**
- * CJS packages the browser SDK needs at runtime. Named, because a bare string here is exactly the
- * kind of thing that silently rots when a dependency is renamed.
- */
-const SDK_CJS_DEPS = {
-    TESTING_LIBRARY: '@testing-library/dom',
-    ARIA_QUERY: 'aria-query',
-};
-/**
- * Name each CJS dep ONLY in the bare form, and only when the app root can resolve it.
- *
- * This used to try three layouts and emit Vite's nested `a > b > c` form when a hoisted lookup
- * failed. The guard asked the wrong question: it tested NODE resolvability, walking the chain
- * segment by segment, and under pnpm that succeeds exactly where Vite fails. Measured on the
- * sveltekit fixture:
- *
- *   ['@testing-library/dom']                                           -> null
- *   ['@reticlehq/browser', '@testing-library/dom']                     -> null
- *   ['@reticlehq/react', '@reticlehq/browser', '@testing-library/dom'] -> emitted
- *
- * So we emitted the three-segment chain, Vite could not follow it, and the boot warning this
- * function exists to prevent appeared anyway — `Failed to resolve dependency: …, present in
- * optimizeDeps.include`, pointing at Reticle, naming a package the developer has never heard of,
- * and forcing a full re-optimization on every cold start. The comment stated the rule correctly and
- * the code broke it.
- *
- * Dropping the nested form loses nothing that matters: the SDK itself is still pre-bundled, and Vite
- * follows its imports when it does that, so these deps are handled as part of it. Naming them
- * separately was belt-and-braces for a locally-aliased SDK, where the bare form resolves anyway.
- */
-export function cjsDepIncludes(appRoot, 
-// Injected so the rule can be tested hermetically. Real module resolution is not: under vitest,
-// `createRequire` from a directory that does not exist still resolves packages out of the runner's
-// own graph, so a filesystem-based test of "nothing is reachable here" silently asserts nothing.
-canResolve = (dep) => null !== resolvableChain([dep], appRoot)) {
-    return [SDK_CJS_DEPS.TESTING_LIBRARY, SDK_CJS_DEPS.ARIA_QUERY].filter(canResolve);
-}
 export function readPairingToken() {
     const override = process.env[ReticleEnv.PAIRING_TOKEN_DIR];
     const dir = override !== undefined && override.length > 0 ? override : join(homedir(), ReticleDir.ROOT);
@@ -292,6 +255,22 @@ export function findDevModule(root, exists) {
  * missing export.
  */
 export function installedSdk(appRoot, canResolve = (dep) => null !== resolvableChain([dep], appRoot)) {
+    try {
+        const pkgPath = join(appRoot, 'package.json');
+        if (existsSync(pkgPath)) {
+            const pkg = JSON.parse(readFileSync(pkgPath, 'utf8'));
+            const deps = { ...(pkg.dependencies ?? {}), ...(pkg.devDependencies ?? {}) };
+            if (deps[RETICLE_SENSOR] !== undefined && deps[RETICLE_PACKAGE] === undefined) {
+                return { specifier: RETICLE_SENSOR, usesInstall: false };
+            }
+            if (deps[RETICLE_PACKAGE] !== undefined) {
+                return { specifier: RETICLE_PACKAGE, usesInstall: true };
+            }
+        }
+    }
+    catch {
+        // Ignore read or parse failures when checking dependencies
+    }
     if (canResolve(RETICLE_PACKAGE))
         return { specifier: RETICLE_PACKAGE, usesInstall: true };
     if (canResolve(RETICLE_SENSOR))
@@ -305,7 +284,13 @@ export function connectModuleSource(options, devModule = null) {
     const sdk = installedSdk(options.root ?? process.cwd());
     const named = sdk.usesInstall ? 'reticle, install' : 'reticle';
     const call = sdk.usesInstall ? 'install();\n' : '';
-    const base = `import { ${named} } from '${sdk.specifier}';\n${call}reticle.connect(${args});\n`;
+    // The only place in a Vite app that can see hot updates. `import.meta.hot` exists per module and
+    // only for modules Vite serves through its own transform; the SDK is a dependency, pre-bundled by
+    // the optimizer, and gets no hot context however it is written — so the channel is handed to it
+    // from here and the SDK owns everything after that (including which events it cares about).
+    // Guarded, because a desktop build has no dev server and therefore no hot context at all.
+    const hot = `if (import.meta.hot) reticle.observeHotUpdates(import.meta.hot);\n`;
+    const base = `import { ${named} } from '${sdk.specifier}';\n${call}reticle.connect(${args});\n${hot}`;
     // AFTER connect: registerStore subscribes through the live SDK, and registering before there is a
     // session to report into drops the first diffs.
     return null === devModule ? base : `${base}import('${devModule}');\n`;
@@ -422,21 +407,11 @@ export function reticle(options = {}) {
         ...(true === options.desktop ? {} : { apply: 'serve' }),
         enforce: 'pre',
         /**
-         * Declare the SDK's CJS runtime deps so Vite pre-bundles them.
-         *
-         * `@testing-library/dom` is what `by: role` matching runs on, and it pulls CJS `aria-query`. When
-         * the SDK resolves from OUTSIDE the app's root — a linked package, a pnpm workspace, `npm link`,
-         * a monorepo alias — Vite skips pre-bundling and the named import dies with "does not provide an
-         * export named 'elementRoles'". That takes the WHOLE SDK down before connect() runs, so there is
-         * no session, no Reticle-side error, and only a console SyntaxError naming a package the
-         * developer has never heard of. Measured on the react-admin demo with the SDK aliased to a local
-         * checkout: zero sessions, and it looked like the app was failing to render.
+         * Declare the SDK itself and the optimizer cache fingerprint.
          *
-         * Declaring them is free when Vite would have found them anyway — but only when they are
-         * actually installed. Naming a package that is not there makes Vite log `Failed to resolve
-         * dependency: …, present in optimizeDeps.include` on every boot, which is a scary line pointing
-         * at Reticle for a problem that does not exist. SvelteKit apps hit exactly that: nothing in that
-         * tree depends on @testing-library/dom.
+         * The browser SDK used to need extra CJS query-engine deps here. It no longer imports that
+         * second accessibility engine, so keeping those names would make Vite pre-bundle packages the
+         * app may not have and blame Reticle for a false `Failed to resolve dependency` warning.
          */
         config(config) {
             // Everything below asks what the APP has installed, so every lookup is rooted here and never
@@ -517,9 +492,6 @@ export function reticle(options = {}) {
                         // given the sensor produces the exact boot warning the note below is about, for a
                         // package that is correctly absent.
                         installedSdk(appRoot).specifier,
-                        // Only in a form that resolves — see above; a name Vite cannot resolve produces a boot
-                        // warning that blames Reticle, and a forced re-optimization on every cold start.
-                        ...cjsDepIncludes(appRoot),
                     ],
                 },
             };

package/dist/installed.d.ts

@@ -24,10 +24,8 @@ export declare function isResolvable(specifier: string, from?: string): boolean;
  *
  * A single-segment chain is just the bare specifier, so this also answers "can the app see it
  * itself". Each further segment is resolved from the PREVIOUS package's directory, which is what
- * Vite does with the `>` form and the only way to name a dependency the app root cannot see: under
- * pnpm (and npm's nested layout) `@testing-library/dom` belongs to `@reticlehq/browser`, not to the
- * user's app. Naming it bare made Vite fail to resolve it and force a re-optimization on every cold
- * boot. SvelteKit ships `svelte > clsx` for the same reason.
+ * Vite does with the `>` form and the only way to name a dependency the app root cannot see under
+ * pnpm or npm's nested layout. SvelteKit ships `svelte > clsx` for the same reason.
  */
 export declare function resolvableChain(chain: readonly string[], from: string): string | null;
 /** The installed SDK's package version, for the HELLO's `sdkVersion`. Node-side only. */

package/dist/installed.js

@@ -15,7 +15,7 @@
  * Silently, for every pnpm user, with no error anywhere.
  */
 import { existsSync, readFileSync, statSync } from 'node:fs';
-import { dirname, join } from 'node:path';
+import { dirname, join, isAbsolute, resolve } from 'node:path';
 import { createRequire } from 'node:module';
 /** The React kit the host app imports the SDK from. Mirrors the constant in index.ts. */
 const RETICLE_PACKAGE = '@reticlehq/react';
@@ -26,7 +26,8 @@ const MANIFEST_SEARCH_DEPTH = 5;
  * `process.cwd()` default matches how Vite itself defaults the root when the config omits it.
  */
 function requireFromApp(from) {
-    return createRequire(join(from, 'package.json'));
+    const absoluteFrom = isAbsolute(from) ? from : resolve(process.cwd(), from);
+    return createRequire(join(absoluteFrom, 'package.json'));
 }
 /**
  * Whether a package can be resolved from the app. Used to avoid declaring an optimizeDeps entry for
@@ -74,10 +75,8 @@ function packageDirOf(specifier, from) {
  *
  * A single-segment chain is just the bare specifier, so this also answers "can the app see it
  * itself". Each further segment is resolved from the PREVIOUS package's directory, which is what
- * Vite does with the `>` form and the only way to name a dependency the app root cannot see: under
- * pnpm (and npm's nested layout) `@testing-library/dom` belongs to `@reticlehq/browser`, not to the
- * user's app. Naming it bare made Vite fail to resolve it and force a re-optimization on every cold
- * boot. SvelteKit ships `svelte > clsx` for the same reason.
+ * Vite does with the `>` form and the only way to name a dependency the app root cannot see under
+ * pnpm or npm's nested layout. SvelteKit ships `svelte > clsx` for the same reason.
  */
 export function resolvableChain(chain, from) {
     let base = from;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@reticlehq/vite-plugin",
-  "version": "2.10.0",
+  "version": "2.12.0",
   "description": "Vite plugin for Reticle: dev-only source-map stamping plus auto-injected reticle.connect(). apply:'serve' guarantees it never ships to production.",
   "type": "module",
   "license": "Apache-2.0",
@@ -41,8 +41,8 @@
   ],
   "dependencies": {
     "@babel/core": "^7.26.0",
-    "@reticlehq/babel-plugin": "2.10.0",
-    "@reticlehq/core": "2.10.0"
+    "@reticlehq/babel-plugin": "2.12.0",
+    "@reticlehq/core": "2.12.0"
   },
   "devDependencies": {
     "@types/babel__core": "^7.20.5",