@vgai/editor 0.2.0

package/vite-plugin-react-game-static.ts

@@ -0,0 +1,98 @@
+/**
+ * vite-plugin-react-game-static — serve the vendored react-rpg game's
+ * runtime-needed `public/` asset subset (Track N, N2 —
+ * docs/REACT-INGEST-LANDING-DESIGN.md D-N7) at the URLs the vendored game's
+ * OWN code computes for them — never a game-source edit (the anti-shim
+ * rule); this is pure host wiring, mirroring `vite-plugin-game-static.ts`'s
+ * precedent for Track P.
+ *
+ * Two call sites, read directly off `vendor/react-games/react-rpg/src`:
+ *
+ *  - `src/features/dialog-manager/dialogs/game-select/index.jsx` has a
+ *    literal `src="/logo-no-bg.png"` — an absolute ROOT path, verbatim.
+ *  - `src/config/constants.js`'s `GET_REF_URL()` builds a tile-asset BASE
+ *    URL from its own `import.meta.url`, slicing off everything from the
+ *    literal substring `'src'` onward and appending `'tiles/'`. Upstream's
+ *    own repo serves this module at `/src/config/constants.js` (Vite root =
+ *    their repo root), so the slice keeps `import.meta.url`'s ORIGIN and
+ *    nothing else, yielding an origin-rooted `/tiles/` URL there.
+ *
+ *    EMPIRICAL FINDING (an earlier vendoring attempt got this wrong — kept
+ *    for the record, since it's not obvious): the vendored folder here is
+ *    named `src/`, matching upstream EXACTLY — NOT renamed (the pixi
+ *    precedent's convention would suggest `game/`, and `docs/REACT-INGEST-
+ *    LANDING-DESIGN.md` D-N5 even suggests it, but a renamed folder actively
+ *    BREAKS this game: this dev server's URL for `constants.js` is
+ *    `http://<host>/vendor/react-games/react-rpg/game/config/constants.js`
+ *    if renamed — which contains NO `'src'` substring anywhere, so
+ *    `indexOf('src')` returns `-1`; `String.prototype.substring` clamps a
+ *    negative end to `0`, so the slice degenerates to `''`, and the computed
+ *    "URL" is the bare string `'tiles/'` — NOT a valid absolute URL. The
+ *    game's own `features/map/map-padding.jsx` then does
+ *    `new URL('./tile.png', REF_URL)`, and `new URL()`'s second argument
+ *    (base) MUST itself be a valid absolute URL or the constructor THROWS
+ *    (`TypeError: Failed to construct 'URL': Invalid base URL`) — verified
+ *    against the real dev server; this is a hard runtime crash the moment
+ *    the dungeon view tries to render a single tile, not a cosmetic issue.
+ *    Keeping the folder named `src/` makes `indexOf('src')` find the REAL
+ *    segment, so the slice yields a genuine origin-rooted URL prefix:
+ *    `http://<host>/vendor/react-games/react-rpg/` + `'tiles/'` ==
+ *    `http://<host>/vendor/react-games/react-rpg/tiles/` — the route this
+ *    plugin serves below. (`verify-unaltered.mjs`'s doc comment records the
+ *    same finding from the zero-diff-script side.)
+ *
+ * Scope: this plugin unconditionally claims `/logo-no-bg.png` and
+ * `/vendor/react-games/react-rpg/tiles/*` at the editor's own root/vendor
+ * path, same tradeoff `vite-plugin-game-static.ts` accepts for
+ * `/pixi-game-static/` — acceptable because nothing else in this repo claims
+ * either path today. `/tiles/*` (a page-relative fallback, in case a future
+ * checkout path ever contains the substring `'src'` in an earlier segment,
+ * which would shift where the slice lands) is also served, defensively.
+ */
+import { readFile } from 'node:fs/promises';
+import { extname, join, normalize, resolve } from 'node:path';
+import type { Plugin } from 'vite';
+
+const MIME: Record<string, string> = {
+  '.png': 'image/png',
+  '.jpg': 'image/jpeg',
+  '.jpeg': 'image/jpeg',
+  '.webp': 'image/webp',
+  '.svg': 'image/svg+xml',
+};
+
+const TILES_URL_PREFIXES = ['/tiles/', '/vendor/react-games/react-rpg/tiles/'];
+
+export function reactGameStaticPlugin(repoRoot: string): Plugin {
+  const publicRoot = resolve(repoRoot, 'vendor/react-games/react-rpg/public');
+  return {
+    name: 'vgai-react-game-static',
+    configureServer(server) {
+      server.middlewares.use(async (req, res, next) => {
+        const url = (req.url ?? '').split('?')[0] ?? '';
+        const tilesPrefix = TILES_URL_PREFIXES.find((p) => url.startsWith(p));
+        const relPath =
+          url === '/logo-no-bg.png'
+            ? url
+            : tilesPrefix && `/tiles/${url.slice(tilesPrefix.length)}`;
+        if (!relPath) return next();
+        try {
+          const filePath = normalize(join(publicRoot, relPath));
+          // path-traversal guard: stay inside publicRoot
+          if (!filePath.startsWith(publicRoot)) {
+            res.statusCode = 403;
+            res.end('forbidden');
+            return;
+          }
+          const buf = await readFile(filePath);
+          res.setHeader('Content-Type', MIME[extname(filePath)] ?? 'application/octet-stream');
+          res.setHeader('Cache-Control', 'no-cache');
+          res.statusCode = 200;
+          res.end(buf);
+        } catch {
+          next();
+        }
+      });
+    },
+  };
+}

package/vite-plugin-react-world-provider.ts

@@ -0,0 +1,81 @@
+/**
+ * Vite plugin: a tiny synthetic ES module that STATICALLY re-exports
+ * `GameProvider` from a given project's `src/ui/game-state.tsx`
+ * (T6.2 slice 3 finding — see `packages/editor/src/adapter-resolver.ts`'s
+ * `loadProjectGameProvider` doc comment for the full mechanism this closes).
+ *
+ * The problem this solves: `resolveDefaultReactAdapter` needs `GameProvider`
+ * from the SAME `game-state.tsx` module instance a react world's entry
+ * module's OWN static relative import (`import { useGameState } from
+ * './src/ui/game-state'`) resolves to — otherwise `<GameProvider>`
+ * and `useGameState`'s `useGame()` read/write DIFFERENT `createContext()`
+ * objects and `useGame()` throws "no Game in context" even though
+ * `<GameProvider>` genuinely wraps the tree. `adapter-resolver.ts` cannot
+ * import `game-state.tsx` directly with a hand-built runtime `/@fs/` string
+ * (`import(/* @vite-ignore *\/ computedPath)`) and expect it to land on the
+ * SAME module: verified empirically (T6.2 slice 3's AC e2e, and this
+ * plugin's own doc history) that Vite's dev server treats a raw dynamic
+ * `/@fs/` fetch differently from its own rewrite of a STATIC relative
+ * import found while transforming a `.tsx` file — the two request URLs
+ * diverge (a query-string difference observed in practice), and since
+ * browser ES module identity is per-exact-URL, that is enough to produce
+ * TWO separate module instances even though both point at the identical
+ * file on disk.
+ *
+ * The fix: make the resolver's own request for `GameProvider` go through
+ * the SAME transform-time static-import rewrite Vite already applies to a
+ * react-world entry's own relative import, by asking Vite to transform a
+ * SYNTHETIC module whose body is nothing but a literal, static
+ * `export { GameProvider } from '/@fs/<projectRoot>/src/ui/
+ * game-state.tsx';` — that specifier is resolved by the SAME plugin
+ * machinery (Vite's own `resolveId`) an entry module's static import goes
+ * through, so both converge on the identical final module.
+ */
+import type { Plugin } from 'vite';
+
+/** The dynamic-import-facing URL prefix (`?root=<projectRoot>` query). */
+export const REACT_WORLD_PROVIDER_PATH = '/__vgai-game-provider';
+
+const VIRTUAL_ID_PREFIX = '\0vgai-game-provider:';
+
+/** Build the dynamic-import specifier `adapter-resolver.ts` uses. */
+export function reactWorldProviderImportSpecifier(projectRoot: string): string {
+  return `${REACT_WORLD_PROVIDER_PATH}?root=${encodeURIComponent(projectRoot)}`;
+}
+
+export function reactWorldProviderPlugin(): Plugin {
+  return {
+    name: 'vgai-react-world-provider',
+    resolveId(id) {
+      if (id.startsWith(REACT_WORLD_PROVIDER_PATH)) {
+        const query = id.slice(REACT_WORLD_PROVIDER_PATH.length);
+        return VIRTUAL_ID_PREFIX + query;
+      }
+      return undefined;
+    },
+    load(id) {
+      if (!id.startsWith(VIRTUAL_ID_PREFIX)) return undefined;
+      const query = id.slice(VIRTUAL_ID_PREFIX.length);
+      const params = new URLSearchParams(query.startsWith('?') ? query.slice(1) : query);
+      const projectRoot = params.get('root');
+      if (!projectRoot) {
+        throw new Error(
+          `vgai-react-world-provider: missing \`?root=\` (got id "${id}") — ` +
+            'reactWorldProviderImportSpecifier() should always supply it.',
+        );
+      }
+      // Windows roots arrive as 'C:\…' — no leading slash and backslashed.
+      // Normalize to Vite's canonical '/@fs/C:/…' form; the bare-concat form
+      // degenerates to '/@fsC:\…', which Vite cannot serve. POSIX roots
+      // (leading '/') keep the original concat shape.
+      const rootUrlPath = projectRoot.replace(/\\/g, '/');
+      const gameStatePath = `/@fs${rootUrlPath.startsWith('/') ? '' : '/'}${rootUrlPath}/src/ui/game-state.tsx`;
+      // A LITERAL static specifier — Vite's own import-analysis rewrites this
+      // the SAME way it rewrites a react-world entry's own relative import
+      // to the same file (both are static specifiers processed by the same
+      // resolver at transform time), which is what makes the two converge on
+      // one module instance.
+      return `export { GameProvider } from ${JSON.stringify(gameStatePath)};\n`;
+    },
+  };
+}

package/vite-plugin-react-world-runtime.ts

@@ -0,0 +1,76 @@
+/**
+ * Vite plugin: a tiny synthetic ES module that STATICALLY re-exports
+ * `createElement` (react), `createRoot`/`flushSync` (react-dom/client,
+ * react-dom), and the engine-published `GameProvider` fallback
+ * (`@engine/react/game-state`) —
+ * PACKAGED-runtime-only sibling of `vite-plugin-react-world-provider.ts`,
+ * closing the "second, deeper gap" that file's mechanism doesn't reach (see
+ * `packages/editor/server/packaged.ts`'s header doc comment, "React-world OID
+ * authoring parity" section, and `adapter-resolver.ts`'s
+ * `resolveReactWorldMountRuntime` doc comment for the full mechanism this
+ * fixes).
+ *
+ * The problem this solves: under the packaged runtime (`packaged.ts` — a
+ * `@vgai/editor` npm package with NO monorepo checkout), the editor's OWN
+ * `react`/`react-dom/client` are STATICALLY bundled into its prebuilt SPA
+ * (`dist/`, built once at `npm run build -w @vgai/editor` time) — a totally
+ * separate, already-built bundle, physically disconnected from the SEPARATE,
+ * project-rooted Vite instance `packaged.ts` boots to serve the opened
+ * project's own module graph (which resolves bare `react` from the
+ * PROJECT's own `node_modules`, per that Vite instance's `root`). Mounting a
+ * react world with `createRoot` from the editor's bundle while the entry
+ * component's hooks run against the project's own `react` produces TWO
+ * separate React module instances — `useContext`/`useState` etc. read/write
+ * different internal singletons, and `useContext` throws on a `null`
+ * dispatcher (confirmed live, `packaged.ts`'s header doc comment).
+ *
+ * `dev.ts`/the Electron `prod.ts` path have no such split (ONE shared Vite
+ * instance + repo-root `vite.config.ts`'s `resolve.dedupe: ['react',
+ * 'react-dom', ...]` already collapses the editor's own react and the
+ * project's react onto one module instance) — this plugin is registered
+ * ONLY on the packaged runtime's project-rooted Vite instance (`packaged.ts`)
+ * plus the root `vitest.config.ts` (so this branch is exercisable from a
+ * headless unit test, same precedent as `reactWorldProviderPlugin`'s own
+ * vitest registration) — never on `dev.ts`/the root `vite.config.ts` dev/
+ * Electron path, which must stay byte-unchanged.
+ *
+ * The fix mirrors `vite-plugin-react-world-provider.ts`'s: ask Vite to
+ * transform a SYNTHETIC module whose body is nothing but literal, STATIC
+ * `export … from '<bare-or-aliased specifier>'` lines — those specifiers go
+ * through the SAME transform-time resolver (and the SAME `optimizeDeps`
+ * prebundle cache) a react-world entry module's own static `import react
+ * from 'react'` goes through, so both converge on the identical `react`/
+ * `react-dom/client` module instances. No `?root=` parameterization is
+ * needed here (unlike the GameProvider plugin): `react`, `react-dom/client`,
+ * and `@engine/react/game-state` are all resolved relative to THIS Vite
+ * instance's own root/aliases, not a per-project file path.
+ */
+import type { Plugin } from 'vite';
+
+/** The dynamic-import-facing URL `adapter-resolver.ts` imports. */
+export const REACT_WORLD_RUNTIME_PATH = '/__vgai-react-world-runtime';
+
+const VIRTUAL_ID = '\0vgai-react-world-runtime';
+
+export function reactWorldRuntimePlugin(): Plugin {
+  return {
+    name: 'vgai-react-world-runtime',
+    resolveId(id) {
+      if (id === REACT_WORLD_RUNTIME_PATH) return VIRTUAL_ID;
+      return undefined;
+    },
+    load(id) {
+      if (id !== VIRTUAL_ID) return undefined;
+      return [
+        "export { createElement } from 'react';",
+        "export { createRoot } from 'react-dom/client';",
+        // `flushSync` — needed by `design-time-layers.ts`'s react-world layer
+        // mount (its synchronous initial render), from the SAME react-dom
+        // peer as `createRoot` above (react-dom/client and react-dom are the
+        // same installed package's two entry points).
+        "export { flushSync } from 'react-dom';",
+        "export { GameProvider as EngineGameProvider } from '@engine/react/game-state';",
+      ].join('\n');
+    },
+  };
+}