@gjsify/cli 0.30.0 → 0.32.0

package/lib/utils/install-global.js

@@ -23,7 +23,7 @@
 import * as fs from 'node:fs';
 import * as os from 'node:os';
 import * as path from 'node:path';
-import { detectNativePackages } from './detect-native-packages.js';
+import { detectHostLibc, detectNativePackages, hostPlatformTokens, platformPackageName, } from './detect-native-packages.js';
 import { buildLauncherShims, buildNativeEnvPreamble, buildShLauncher, isGjsBundlePath, parseShebang, pickBinMap, } from './bin-shim.js';
 /**
  * Compute the canonical global install layout for the current user. Honours
@@ -63,9 +63,43 @@ export const GJS_ENGINE_PACKAGES = [
     '@gjsify/lightningcss-native',
     '@gjsify/oxfmt-native',
 ];
-/** True when `<prefix>/node_modules/@gjsify/rolldown-native` is laid down. */
-export function hasBundlerEngineInstalled(prefix) {
-    return fs.existsSync(path.join(prefix, 'node_modules', '@gjsify/rolldown-native', 'package.json'));
+/**
+ * The one engine whose absence is fatal rather than degrading: `gjsify build`
+ * has no fallback under GJS. Named separately because two different questions
+ * ("what do we install") and ("is a build possible") want different sets.
+ */
+export const BUNDLER_ENGINE_PACKAGE = '@gjsify/rolldown-native';
+/**
+ * True when a bundler engine `gjsify build` can actually LOAD is reachable from
+ * `dir`.
+ *
+ * This used to `existsSync` the bridge's own `package.json` and stop there. That
+ * answer was correct before ADR 0017 and is wrong after it: the bridge is now
+ * pure TypeScript (`files: ["lib", "meson.build", "src/rust", "src/vala"]`) and
+ * the binary lives in a per-target child (`@gjsify/rolldown-native-<os>-<arch>`).
+ * So "bridge present, child missing" reported `true` — which is why
+ * `self-update`'s repair gate could say "Already up to date" about a prefix whose
+ * engine cannot load. A live defect, not a hypothetical one.
+ *
+ * Asks `detectNativePackages` instead, which is the same walk-up
+ * `findRolldownNativeDir` performs at BUILD time. That matters more than the
+ * shortcut it replaces: an installer that disagrees with the builder about
+ * whether the engine is present is worse than one that is merely slow. It also
+ * makes the gjsify monorepo a no-op — the workspace symlink resolves — which is
+ * what keeps ADR 0001's non-destructive invariant safe from a registry copy
+ * landing on top of `packages/infra/rolldown-native`.
+ *
+ * `dir` is a prefix for a global install and a project root for a project one;
+ * the walk handles both.
+ */
+export function hasBundlerEngineInstalled(dir) {
+    const names = new Set(detectNativePackages(dir).map((p) => p.name));
+    if (names.has(BUNDLER_ENGINE_PACKAGE))
+        return true;
+    // The per-target child is the thing that actually carries the binary, so its
+    // presence is the honest positive answer even when the umbrella is absent.
+    const libc = detectHostLibc(process.platform);
+    return hostPlatformTokens(process.platform, process.arch, libc).some((token) => names.has(platformPackageName(BUNDLER_ENGINE_PACKAGE, token)));
 }
 /**
  * Best-effort install of the GJS-native engine packages into a global prefix.
@@ -263,12 +297,100 @@ function readShebangOf(file) {
 function readJson(file) {
     return JSON.parse(fs.readFileSync(file, 'utf-8'));
 }
+/**
+ * Is the global layout the user's own, or has a caller redirected it?
+ *
+ * `GJSIFY_GLOBAL_PREFIX` / `GJSIFY_GLOBAL_BIN_DIR` are the escape hatches
+ * {@link defaultGlobalLayout} documents for tests, and a caller that sets them
+ * has taken over placement — so "which `gjsify` will PATH resolve next" stops
+ * being a question about THEIR intent. `self-update` gates its fatal PATH check
+ * on this: without it, every harness installing into a temp prefix it never put
+ * on PATH is told its update did not take effect, which is true and useless.
+ * Caught by `tests/e2e/global-install-engine`.
+ *
+ * @param env injectable so both answers are testable without mutating the real
+ *   environment mid-suite.
+ */
+export function globalLayoutIsDefault(env = process.env) {
+    return !env.GJSIFY_GLOBAL_PREFIX && !env.GJSIFY_GLOBAL_BIN_DIR;
+}
+/**
+ * The path module for a TARGET platform, not for the host.
+ *
+ * Load-bearing for every function below that takes a `platform`. `path.resolve`
+ * is host-bound: on Linux `path.resolve('C:\\tools')` returns
+ * `<cwd>/C:\tools`, because posix has no notion of a drive letter. So a function
+ * that accepts `platform` and then calls the host's `path` is only pretending to
+ * be portable — it silently mangles Windows input everywhere except Windows,
+ * which is exactly the class of bug an injected platform is supposed to expose.
+ * Caught by `resolve-bin-on-path.spec.ts`, which asserts real `C:\…` semantics
+ * from Linux.
+ */
+function pathFor(platform) {
+    return platform === 'win32' ? path.win32 : path.posix;
+}
+/** PATH split into resolved directory entries, in search order. */
+function searchPathEntries(pathValue, platform) {
+    const p = pathFor(platform);
+    const sep = platform === 'win32' ? ';' : ':';
+    return pathValue
+        .split(sep)
+        .filter(Boolean)
+        .map((entry) => p.resolve(entry));
+}
 /** Returns `true` if `binDir` is on the user's PATH. */
 export function binDirOnPath(binDir) {
-    const PATH = process.env.PATH ?? '';
-    const sep = process.platform === 'win32' ? ';' : ':';
-    const want = path.resolve(binDir);
-    return PATH.split(sep).some((entry) => entry && path.resolve(entry) === want);
+    const want = pathFor(process.platform).resolve(binDir);
+    return searchPathEntries(process.env.PATH ?? '', process.platform).includes(want);
+}
+/** cmd.exe's default when PATHEXT is unset. `.CMD` is the one npm-style shims need. */
+const DEFAULT_PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS;.MSC';
+/**
+ * Resolve `binName` the way the user's shell will: the FIRST hit in PATH order.
+ *
+ * WHY THIS IS NOT `binDirOnPath`. That answers "is our dir on PATH", which is
+ * necessary but not sufficient for anything that CHANGES which binary runs:
+ * `~/.local/bin` can be on PATH and still lose to an npm-global `gjsify` earlier
+ * in it. `self-update` reported "Updated to v0.31.0" on exactly that host while
+ * the shell kept resolving a v0.26.0 install five releases behind — and the user
+ * then re-hit a bug fixed three releases earlier and reported it as new (#1064).
+ * "Which one wins" is the question, so this returns the winning PATH.
+ *
+ * WINDOWS. An extension-less name is not executable there; cmd.exe and pwsh
+ * append each `PATHEXT` entry, which is how the `.cmd` shim `bin-shim.ts` writes
+ * gets found. The bare name is probed LAST so a git-bash/MSYS `sh` shim is still
+ * reported rather than missed. `platform`/`pathExt`/`exists` are injectable for
+ * the same reason `dirLinkTarget` takes `linkType`: nothing in CI resolves a bin
+ * on a Windows host, so an injected `'win32'` is the ONLY way that branch is ever
+ * EXECUTED — and an unexecutable Windows branch is exactly how the `'dir'` bug in
+ * `dir-link.ts` shipped.
+ *
+ * @returns the absolute path of the winning candidate, or `null` when PATH holds none.
+ */
+export function resolveBinOnPath(binName, opts = {}) {
+    const platform = opts.platform ?? process.platform;
+    const pathValue = opts.pathValue ?? process.env.PATH ?? '';
+    const exists = opts.exists ?? fs.existsSync;
+    // On win32 the extensions come FIRST (what cmd.exe/pwsh actually launch) and
+    // the bare name last (git-bash). Elsewhere there is only the bare name.
+    const suffixes = platform === 'win32'
+        ? [
+            ...(opts.pathExt ?? process.env.PATHEXT ?? DEFAULT_PATHEXT)
+                .split(';')
+                .filter(Boolean)
+                .map((ext) => (ext.startsWith('.') ? ext : `.${ext}`)),
+            '',
+        ]
+        : [''];
+    const p = pathFor(platform);
+    for (const dir of searchPathEntries(pathValue, platform)) {
+        for (const suffix of suffixes) {
+            const candidate = p.join(dir, `${binName}${suffix}`);
+            if (exists(candidate))
+                return candidate;
+        }
+    }
+    return null;
 }
 /**
  * Extracts the package name from a spec like `name@1.2`, `@scope/name`,

package/lib/utils/oxc-resolve.d.ts

@@ -69,7 +69,7 @@ export declare function shouldUseNativeOxfmt(): Promise<boolean>;
  *
  * oxlint: always spawned via its Node ESM launcher on a real Node host
  * (`nodeBinary()`: `process.execPath` under Node, PATH `node` under the GJS
- * bundle where `process.execPath` is the bundle itself) so the JS plugin host
+ * bundle where `process.execPath` is the `gjs` interpreter) so the JS plugin host
  * is available — required for the `jsPlugins`-wired `gjsify/register-class-order`
  * rule. Under GJS a `node` on PATH is required (oxlint has no native bridge
  * yet); its absence surfaces as a clear OxcNotFoundError, never a hang.

package/lib/utils/oxc-resolve.js

@@ -53,6 +53,7 @@ import { pathToFileURL } from 'node:url';
 import { hostLibc } from './platform-check.js';
 import { findWorkspaceRoot } from './workspace-root.js';
 import { resolveNpmPackage } from './resolve-npm-package.js';
+import { activateNativePrebuilds } from './gi-search-path.js';
 import { nodeBinary } from './run-node.js';
 import { spawnToCompletion } from './spawn.js';
 import { isGjs, gjsExit } from '@gjsify/rolldown-plugin-gjsify/runtime';
@@ -245,6 +246,10 @@ async function tryLoadNativeOxfmt() {
         if (!isGjs())
             return null;
         try {
+            // Same reason as `bundler-pick.ts`'s `tryLoadNative()`: put the
+            // prebuild on girepository's own search paths so the bridge loads
+            // without the `gjsify` launcher having exported anything. ADR 0021.
+            activateNativePrebuilds();
             const specifier = '@gjsify/oxfmt-native';
             const resolved = resolveNpmPackage(specifier, { bundleUrl: import.meta.url }) ??
                 createRequire(import.meta.url).resolve(specifier);
@@ -293,7 +298,7 @@ export async function shouldUseNativeOxfmt() {
  *
  * oxlint: always spawned via its Node ESM launcher on a real Node host
  * (`nodeBinary()`: `process.execPath` under Node, PATH `node` under the GJS
- * bundle where `process.execPath` is the bundle itself) so the JS plugin host
+ * bundle where `process.execPath` is the `gjs` interpreter) so the JS plugin host
  * is available — required for the `jsPlugins`-wired `gjsify/register-class-order`
  * rule. Under GJS a `node` on PATH is required (oxlint has no native bridge
  * yet); its absence surfaces as a clear OxcNotFoundError, never a hang.
@@ -323,11 +328,10 @@ export async function runOxc(tool, args, opts = {}) {
 /**
  * Spawn an oxc tool via its Node ESM launcher (`node_modules/<tool>/bin/…`) on
  * a real Node host. CRITICAL: use `nodeBinary()`, not `process.execPath`
- * directly — under the committed GJS bundle `process.execPath` is the CLI
- * bundle path (`gjs`/the `.mjs`), so spawning it re-executes the CLI with the
- * launcher as its first positional (yargs prints top-level help) and the parent
- * hangs waiting on a child that never does the intended work. `nodeBinary()`
- * resolves to PATH `node` under GJS, so the launcher runs on Node as required.
+ * directly — under GJS `process.execPath` is the `gjs` interpreter, so spawning
+ * it runs the Node ESM launcher under GJS, where the plugin host does not exist.
+ * `nodeBinary()` resolves to PATH `node` under GJS, so the launcher runs on Node
+ * as required.
  *
  * `completion: 'return'`: `lint` / `format` / `fix` hand the tool's exit code
  * to `setOxcExitCode`, which deliberately does NOT terminate the process on a

package/lib/utils/stdin.d.ts

@@ -1,19 +1,9 @@
 /**
  * Read the whole of stdin as UTF-8. Works on Node and under the GJS bundle.
  *
- * Branches on WHICH RUNTIME CAN WORK, not on which capability is present. The
- * distinction matters because the two branches are not interchangeable:
- * `readFileSync(0)` is correct on Node/Bun/Deno and can NEVER work under GJS —
- * `@gjsify/fs` has no numeric-fd path, so the `0` is coerced to a relative
- * PATH and the call opens `./0`. A GJS run that reaches that line is already
- * lost, so using it as GJS's fallback only converts a clear failure into
- * `ENOENT … read '0'`, which is what a capability probe returning a false
- * negative did.
- *
- * So: the presence of `imports.gi` decides. On GJS both GJS readers are tried
- * and a failure THROWS with what was attempted; the Node reader is never
- * reached. Off GJS there is no gi namespace and `readFileSync(0)` is the only
- * and correct answer.
+ * Synchronous on purpose: the callers are CLI argument-parsing paths that run
+ * before any main loop exists, and the async `process.stdin` route carries the
+ * documented resume/pause races (see `utils/prompt.ts`).
  */
 export declare function readStdinText(): string;
 /**

package/lib/utils/stdin.js

@@ -1,119 +1,40 @@
 // SPDX-License-Identifier: MIT
 // Read ALL of stdin, on Node AND inside the committed GJS bundles.
 //
-// `readFileSync(0, 'utf-8')` is the Node idiom for "slurp stdin", and it is
-// what `gjsify affected --changed-from-stdin` used. It does NOT survive the
-// GJS bundle: `@gjsify/fs` has no numeric-file-descriptor path, so the `0` is
-// coerced to a PATH and the call opens the relative file `./0` — every GJS
-// caller died with
+// `readFileSync(0, 'utf-8')` is the Node idiom for "slurp stdin". It used NOT to
+// survive the GJS bundle: `@gjsify/fs` had no numeric-file-descriptor path, so
+// the `0` was coerced to a PATH and the call opened the relative file `./0` —
+// every GJS caller died with
 //
 //     Error: ENOENT: … read '0'   (readStdinLines → readFileSync)
 //
 // which silently disabled the ONE fixture-driven entry point AGENTS.md
 // documents for testing the CI classifier (`--changed-from-stdin`).
 //
-// Under GJS we therefore read fd 0 through `GioUnix.InputStream`. Two
-// deliberate choices:
+// THE GAP IS CLOSED AT THE CORE, so the workaround is gone: `@gjsify/fs` maps
+// the parent-supplied descriptors 0/1/2 onto the process's own Unix streams
+// (`packages/node/fs/src/std-fd.ts`, reached from `readFileSync` through
+// `sync.ts`), which makes the Node idiom mean the same thing under GJS. This
+// module used to carry two GJS-only readers for that gap — a
+// `GioUnix.InputStream` chunk loop and a `/dev/stdin` `Gio.File` fallback —
+// plus a runtime branch to choose between them. All three were consumer-side
+// repair for a missing core capability.
 //
-//   - `globalThis.imports.gi.GioUnix` rather than a `gi://GioUnix` import.
-//     `packages/infra/cli/lib/**` is ALSO the Node entry point of
-//     `@gjsify/cli` (`bin: lib/index.js`); a static `gi://` import anywhere
-//     reachable from it breaks `gjsify` on Node, and a dynamic one would need
-//     an `@girs/giounix-2.0` type dependency the CLI does not otherwise have.
-//     The legacy `imports.gi` form is the sanctioned GJS-bootstrap escape
-//     hatch (AGENTS.md "Reading globals", exception 4) and adds NO new typelib
-//     to the classifier bundle — `gi://GioUnix?version=2.0` is already in its
-//     import graph via `@gjsify/fs`.
-//   - a synchronous read. The callers are CLI argument-parsing paths that run
-//     before any main loop exists, and the async `process.stdin` route carries
-//     the documented resume/pause races (see `utils/prompt.ts`).
+// Anything re-adding a GJS branch HERE is re-adding the workaround. If stdin
+// misbehaves under GJS the defect is in `@gjsify/fs` and belongs there, with a
+// test — that is what made the branch removable in the first place
+// (`packages/node/fs/src/fd-ops.spec.ts` + `tests/e2e/fs-std-fd`, which needs a
+// real pipe and so cannot live in a unit spec).
 import { readFileSync } from 'node:fs';
-const CHUNK = 64 * 1024;
-/** Read fd 0 to EOF under GJS via GioUnix (no `@gjsify/fs` fd support needed). */
-function readStdinTextGioUnix() {
-    const gi = giNamespace();
-    const GioUnix = gi?.GioUnix;
-    if (typeof GioUnix?.InputStream !== 'function') {
-        throw new Error('GioUnix.InputStream is unavailable');
-    }
-    const stream = new GioUnix.InputStream({ fd: 0, close_fd: false });
-    const chunks = [];
-    let total = 0;
-    for (;;) {
-        const bytes = stream.read_bytes(CHUNK, null);
-        if (bytes.get_size() === 0)
-            break;
-        const arr = bytes.toArray();
-        chunks.push(arr);
-        total += arr.length;
-    }
-    if (total === 0)
-        return '';
-    const buf = new Uint8Array(total);
-    let offset = 0;
-    for (const c of chunks) {
-        buf.set(c, offset);
-        offset += c.length;
-    }
-    return new TextDecoder().decode(buf);
-}
-/**
- * Read stdin under GJS through Gio ALONE, without GioUnix.
- *
- * `/dev/stdin` is fd 0 by another name, and `Gio` is present in every bundle
- * that can reach this code at all. This exists because the GioUnix route has
- * been observed to be unavailable on a host where it should have worked, and a
- * second independent mechanism is cheaper than another round of guessing.
- */
-function readStdinTextGioFile() {
-    const gi = giNamespace();
-    const Gio = gi?.Gio;
-    if (!Gio?.File)
-        throw new Error('Gio.File is unavailable');
-    const [ok, contents] = Gio.File.new_for_path('/dev/stdin').load_contents(null);
-    if (!ok)
-        throw new Error('Gio.File.load_contents("/dev/stdin") returned false');
-    return new TextDecoder().decode(contents);
-}
-/**
- * The GJS `imports.gi` namespace, or `undefined` when not running on GJS.
- * Same optional-chained probe as `isGjs()` — off GJS `imports` is simply
- * absent and the read yields `undefined`; there is no throw path.
- */
-function giNamespace() {
-    return globalThis.imports?.gi;
-}
 /**
  * Read the whole of stdin as UTF-8. Works on Node and under the GJS bundle.
  *
- * Branches on WHICH RUNTIME CAN WORK, not on which capability is present. The
- * distinction matters because the two branches are not interchangeable:
- * `readFileSync(0)` is correct on Node/Bun/Deno and can NEVER work under GJS —
- * `@gjsify/fs` has no numeric-fd path, so the `0` is coerced to a relative
- * PATH and the call opens `./0`. A GJS run that reaches that line is already
- * lost, so using it as GJS's fallback only converts a clear failure into
- * `ENOENT … read '0'`, which is what a capability probe returning a false
- * negative did.
- *
- * So: the presence of `imports.gi` decides. On GJS both GJS readers are tried
- * and a failure THROWS with what was attempted; the Node reader is never
- * reached. Off GJS there is no gi namespace and `readFileSync(0)` is the only
- * and correct answer.
+ * Synchronous on purpose: the callers are CLI argument-parsing paths that run
+ * before any main loop exists, and the async `process.stdin` route carries the
+ * documented resume/pause races (see `utils/prompt.ts`).
  */
 export function readStdinText() {
-    if (!giNamespace())
-        return readFileSync(0, 'utf-8');
-    const attempts = [];
-    for (const read of [readStdinTextGioUnix, readStdinTextGioFile]) {
-        try {
-            return read();
-        }
-        catch (err) {
-            attempts.push(`${read.name}: ${err.message}`);
-        }
-    }
-    throw new Error(`gjsify: cannot read stdin under GJS. Tried ${attempts.join('; ')}. ` +
-        'Pass the input as an argument instead (e.g. --base <ref> rather than --changed-from-stdin).');
+    return readFileSync(0, 'utf-8');
 }
 /**
  * Read stdin and split it into trimmed, non-empty lines. Accepts LF and CRLF

package/lib/utils/system-gi.js

@@ -87,7 +87,16 @@
 // bundle's first line runs.
 import { spawnSync } from 'node:child_process';
 import { statSync } from 'node:fs';
-import { basename, dirname, join } from 'node:path';
+// POSIX path semantics, not the HOST's. This function answers a question about
+// a darwin filesystem — `platform` is a PARAMETER, so the host running the code
+// may be any of the three. Node's default `join`/`dirname`/`basename` follow the
+// host, so on win32 `join('/usr/local/lib', 'girepository-1.0')` becomes
+// `\usr\local\lib\girepository-1.0` and never matches the darwin path the
+// caller (or the injected `existsDir`) is holding. Measured on the Windows leg:
+// three `systemGiLibraryDirs` specs returned `[]` where they assert a prefix.
+// `PROBED_GI_LIBDIRS` is darwin-only, so POSIX is always the right dialect here.
+import { posix } from 'node:path';
+const { basename, dirname, join } = posix;
 /**
  * Prefixes a macOS GI stack is installed under in practice — probed, never
  * assumed: each is accepted only when it actually holds a `girepository-1.0/`.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@gjsify/cli",
-    "version": "0.30.0",
+    "version": "0.32.0",
     "description": "CLI for Gjsify",
     "type": "module",
     "main": "lib/index.js",
@@ -101,6 +101,11 @@
             "__PACKAGE_VERSION__": {
                 "field": "version"
             }
+        },
+        "os": {
+            "linux": "supported",
+            "darwin": "supported",
+            "win32": "supported"
         }
     },
     "files": [
@@ -129,19 +134,19 @@
         "cli"
     ],
     "dependencies": {
-        "@gjsify/buffer": "^0.30.0",
-        "@gjsify/create-app": "^0.30.0",
-        "@gjsify/node-globals": "^0.30.0",
-        "@gjsify/node-polyfills": "^0.30.0",
-        "@gjsify/npm-registry": "^0.30.0",
-        "@gjsify/resolve-npm": "^0.30.0",
-        "@gjsify/rolldown-plugin-gjsify": "^0.30.0",
-        "@gjsify/rolldown-plugin-pnp": "^0.30.0",
-        "@gjsify/semver": "^0.30.0",
-        "@gjsify/tar": "^0.30.0",
-        "@gjsify/tsc": "^0.30.0",
-        "@gjsify/web-polyfills": "^0.30.0",
-        "@gjsify/workspace": "^0.30.0",
+        "@gjsify/buffer": "^0.32.0",
+        "@gjsify/create-app": "^0.32.0",
+        "@gjsify/node-globals": "^0.32.0",
+        "@gjsify/node-polyfills": "^0.32.0",
+        "@gjsify/npm-registry": "^0.32.0",
+        "@gjsify/resolve-npm": "^0.32.0",
+        "@gjsify/rolldown-plugin-gjsify": "^0.32.0",
+        "@gjsify/rolldown-plugin-pnp": "^0.32.0",
+        "@gjsify/semver": "^0.32.0",
+        "@gjsify/tar": "^0.32.0",
+        "@gjsify/tsc": "^0.32.0",
+        "@gjsify/web-polyfills": "^0.32.0",
+        "@gjsify/workspace": "^0.32.0",
         "cosmiconfig": "^9.0.2",
         "get-tsconfig": "^4.14.0",
         "pkg-types": "^2.3.1",
@@ -149,13 +154,13 @@
         "yargs": "^18.0.0"
     },
     "devDependencies": {
-        "@gjsify/unit": "^0.30.0",
+        "@gjsify/unit": "^0.32.0",
         "@types/yargs": "^17.0.35",
         "typescript": "^6.0.3"
     },
     "peerDependencies": {
-        "@gjsify/oxfmt-native": "^0.30.0",
-        "@gjsify/rolldown-native": "^0.30.0"
+        "@gjsify/oxfmt-native": "^0.32.0",
+        "@gjsify/rolldown-native": "^0.32.0"
     },
     "peerDependenciesMeta": {
         "@gjsify/oxfmt-native": {

package/showcases.json

@@ -5,57 +5,49 @@
             "name": "canvas2d-fireworks",
             "category": "dom",
             "package": "@gjsify/example-dom-canvas2d-fireworks",
-            "description": "Colorful fireworks Canvas 2D example with Adwaita controls",
-            "needsWebgl": false
+            "description": "Colorful fireworks Canvas 2D example with Adwaita controls"
         },
         {
             "name": "excalibur-jelly-jumper",
             "category": "dom",
             "package": "@gjsify/example-dom-excalibur-jelly-jumper",
-            "description": "Excalibur.js jelly-jumper game",
-            "needsWebgl": false
+            "description": "Excalibur.js jelly-jumper game"
         },
         {
             "name": "three-geometry-teapot",
             "category": "dom",
             "package": "@gjsify/example-dom-three-geometry-teapot",
-            "description": "Three.js Utah teapot",
-            "needsWebgl": true
+            "description": "Three.js Utah teapot"
         },
         {
             "name": "three-postprocessing-pixel",
             "category": "dom",
             "package": "@gjsify/example-dom-three-postprocessing-pixel",
-            "description": "Three.js postprocessing pixel demo",
-            "needsWebgl": true
+            "description": "Three.js postprocessing pixel demo"
         },
         {
             "name": "webrtc-loopback",
             "category": "dom",
             "package": "@gjsify/example-dom-webrtc-loopback",
-            "description": "WebRTC data-channel loopback: two local peers exchange offer/answer + ICE, then echo messages over an RTCDataChannel",
-            "needsWebgl": false
+            "description": "WebRTC data-channel loopback: two local peers exchange offer/answer + ICE, then echo messages over an RTCDataChannel"
         },
         {
             "name": "minimalist-browser",
             "category": "dom",
             "package": "@gjsify/example-dom-minimalist-browser",
-            "description": "Minimalist browser with URL bar + back/forward + iframe content area; same code runs in browser (real iframe) and GJS (IFrameBridge over WebKit.WebView)",
-            "needsWebgl": false
+            "description": "Minimalist browser with URL bar + back/forward + iframe content area; same code runs in browser (real iframe) and GJS (IFrameBridge over WebKit.WebView)"
         },
         {
             "name": "express-webserver",
             "category": "node",
             "package": "@gjsify/example-node-express-webserver",
-            "description": "Express web server on GJS via @gjsify/http",
-            "needsWebgl": false
+            "description": "Express web server on GJS via @gjsify/http"
         },
         {
             "name": "adwaita-storybook",
             "category": "gtk",
             "package": "@gjsify/example-gtk-adwaita-storybook",
-            "description": "Interactive Libadwaita component browser — author one story per widget, rendered natively (GTK) and in the browser",
-            "needsWebgl": false
+            "description": "Interactive Libadwaita component browser — author one story per widget, rendered natively (GTK) and in the browser"
         }
     ]
 }