@vgai/engine 0.5.15 → 0.5.17

package/dist/runtime/dev-layers.d.ts

@@ -1,34 +0,0 @@
-/**
- * THE one owner of "are dev layers enabled" (`vgai.project.json`'s `dev: true`
- * root flag). Every reader that has to answer that question calls
- * {@link devLayersEnabled}; there is deliberately NO second source of truth —
- * not a module-level cached boolean, not a `globalThis` flag, not a per-host
- * copy of the `import.meta.env` read below. A dev GUI that ships to players
- * because two places disagreed about what "dev" means is exactly the failure
- * this single owner exists to make impossible.
- *
- * Ownership, stated in one place (the build rule):
- *  - OWNER: this function. It resolves the answer; nothing else derives it.
- *  - SHARERS: `mountManifestRoots` (the ship gate — a dev root only mounts
- *    when this returns true). Any future host that mounts manifest roots
- *    itself calls this too, with its own `override`.
- *  - TEARDOWN: none. This is a pure predicate over build config and one
- *    caller-supplied argument — it owns no resource, allocates nothing, and
- *    has no lifecycle to end.
- *
- * The three inputs, highest precedence first:
- *  1. `override` — the explicit per-mount answer. A headless test, a capture
- *     harness, or a host that knows better passes `true`/`false` and gets
- *     exactly that. Passing `undefined` (or omitting it) means "decide for
- *     me" and falls through.
- *  2. A dev build — `import.meta.env.DEV`. The ordinary local/editor case:
- *     dev layers are on.
- *  3. A production build's EXPLICIT opt-in — `VITE_VGAI_DEV_LAYERS=true`.
- *     Shipping the dev GUI in a production bundle is a real, legitimate
- *     choice (an internal playtest build, a QA build), and it must be an
- *     opt-in someone had to type, never something a default drifts into.
- *
- * Anything else — a production build with no opt-in — is `false`.
- */
-export declare function devLayersEnabled(override?: boolean | undefined): boolean;
-//# sourceMappingURL=dev-layers.d.ts.map

package/dist/runtime/dev-layers.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"dev-layers.d.ts","sourceRoot":"","sources":["../../src/runtime/dev-layers.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+BG;AACH,wBAAgB,gBAAgB,CAAC,QAAQ,CAAC,EAAE,OAAO,GAAG,SAAS,GAAG,OAAO,CAaxE"}

package/dist/runtime/dev-layers.js

@@ -1,46 +0,0 @@
-/**
- * THE one owner of "are dev layers enabled" (`vgai.project.json`'s `dev: true`
- * root flag). Every reader that has to answer that question calls
- * {@link devLayersEnabled}; there is deliberately NO second source of truth —
- * not a module-level cached boolean, not a `globalThis` flag, not a per-host
- * copy of the `import.meta.env` read below. A dev GUI that ships to players
- * because two places disagreed about what "dev" means is exactly the failure
- * this single owner exists to make impossible.
- *
- * Ownership, stated in one place (the build rule):
- *  - OWNER: this function. It resolves the answer; nothing else derives it.
- *  - SHARERS: `mountManifestRoots` (the ship gate — a dev root only mounts
- *    when this returns true). Any future host that mounts manifest roots
- *    itself calls this too, with its own `override`.
- *  - TEARDOWN: none. This is a pure predicate over build config and one
- *    caller-supplied argument — it owns no resource, allocates nothing, and
- *    has no lifecycle to end.
- *
- * The three inputs, highest precedence first:
- *  1. `override` — the explicit per-mount answer. A headless test, a capture
- *     harness, or a host that knows better passes `true`/`false` and gets
- *     exactly that. Passing `undefined` (or omitting it) means "decide for
- *     me" and falls through.
- *  2. A dev build — `import.meta.env.DEV`. The ordinary local/editor case:
- *     dev layers are on.
- *  3. A production build's EXPLICIT opt-in — `VITE_VGAI_DEV_LAYERS=true`.
- *     Shipping the dev GUI in a production bundle is a real, legitimate
- *     choice (an internal playtest build, a QA build), and it must be an
- *     opt-in someone had to type, never something a default drifts into.
- *
- * Anything else — a production build with no opt-in — is `false`.
- */
-export function devLayersEnabled(override) {
-    if (override !== undefined)
-        return override;
-    // `import.meta` is cast whole, not just its `.env`: this module is reachable
-    // from programs whose tsconfig does not pull in `vite/client` (the session
-    // client's, for one, which reaches the three adapter transitively), and there
-    // `ImportMeta` has no declared `env` at all. The cast keeps the single owner
-    // of the dev answer importable from ANY program rather than forcing every
-    // downstream tsconfig to adopt Vite's ambient types.
-    const env = import.meta.env;
-    if (env?.DEV === true)
-        return true;
-    return env?.VITE_VGAI_DEV_LAYERS === 'true';
-}

package/src/runtime/dev-layers.ts

@@ -1,46 +0,0 @@
-/**
- * THE one owner of "are dev layers enabled" (`vgai.project.json`'s `dev: true`
- * root flag). Every reader that has to answer that question calls
- * {@link devLayersEnabled}; there is deliberately NO second source of truth —
- * not a module-level cached boolean, not a `globalThis` flag, not a per-host
- * copy of the `import.meta.env` read below. A dev GUI that ships to players
- * because two places disagreed about what "dev" means is exactly the failure
- * this single owner exists to make impossible.
- *
- * Ownership, stated in one place (the build rule):
- *  - OWNER: this function. It resolves the answer; nothing else derives it.
- *  - SHARERS: `mountManifestRoots` (the ship gate — a dev root only mounts
- *    when this returns true). Any future host that mounts manifest roots
- *    itself calls this too, with its own `override`.
- *  - TEARDOWN: none. This is a pure predicate over build config and one
- *    caller-supplied argument — it owns no resource, allocates nothing, and
- *    has no lifecycle to end.
- *
- * The three inputs, highest precedence first:
- *  1. `override` — the explicit per-mount answer. A headless test, a capture
- *     harness, or a host that knows better passes `true`/`false` and gets
- *     exactly that. Passing `undefined` (or omitting it) means "decide for
- *     me" and falls through.
- *  2. A dev build — `import.meta.env.DEV`. The ordinary local/editor case:
- *     dev layers are on.
- *  3. A production build's EXPLICIT opt-in — `VITE_VGAI_DEV_LAYERS=true`.
- *     Shipping the dev GUI in a production bundle is a real, legitimate
- *     choice (an internal playtest build, a QA build), and it must be an
- *     opt-in someone had to type, never something a default drifts into.
- *
- * Anything else — a production build with no opt-in — is `false`.
- */
-export function devLayersEnabled(override?: boolean | undefined): boolean {
-  if (override !== undefined) return override;
-  // `import.meta` is cast whole, not just its `.env`: this module is reachable
-  // from programs whose tsconfig does not pull in `vite/client` (the session
-  // client's, for one, which reaches the three adapter transitively), and there
-  // `ImportMeta` has no declared `env` at all. The cast keeps the single owner
-  // of the dev answer importable from ANY program rather than forcing every
-  // downstream tsconfig to adopt Vite's ambient types.
-  const env = (import.meta as unknown as { env?: unknown }).env as
-    | { DEV?: boolean | undefined; VITE_VGAI_DEV_LAYERS?: string | undefined }
-    | undefined;
-  if (env?.DEV === true) return true;
-  return env?.VITE_VGAI_DEV_LAYERS === 'true';
-}