@gjsify/cli 0.23.0 → 0.24.1

package/lib/utils/detect-native-packages.js

@@ -22,33 +22,42 @@ import { readdirSync, existsSync } from 'node:fs';
 import { join, resolve } from 'node:path';
 import { readPackageJson } from './pkg-json.js';
 /**
- * Map a Node `process.arch` value to the uname-style spelling used by the
- * Vala/meson bridges, which stage into `prebuilds/linux-x86_64/` (the output
- * of `uname -m` on the build host).
+ * Map a Node `process.arch` value to the uname-style spelling the Vala/meson
+ * bridges used to stage into (`prebuilds/linux-x86_64/`, the output of
+ * `uname -m` on the build host).
+ *
+ * LEGACY. Every `@gjsify/*` package now declares and stages the node spelling
+ * (`linux-x64`); this table exists only so the CLI can still load a prebuild
+ * out of a tarball published before the rename. See
+ * {@link prebuildDirCandidates}.
  */
-const NODE_ARCH_TO_UNAME = {
+const NODE_ARCH_TO_LEGACY_UNAME = {
     x64: 'x86_64',
     arm64: 'aarch64',
     arm: 'armv7',
     ia32: 'i686',
 };
 /**
- * Arch spellings that name the same target. Mirrors `ARCH_ALIASES` in
- * `scripts/audit-runtimes.mjs` — that script canonicalises
- * `package.json#gjsify.platforms` the same way for the platform-support
- * matrix, and the two MUST agree or a package could pass the audit while the
- * CLI fails to find its artifact.
+ * Arch spellings that name the same target, folded onto the NODE spelling.
+ * Mirrors `ARCH_ALIASES` in `scripts/audit-runtimes.mjs` — that script
+ * canonicalises `package.json#gjsify.platforms` the same way for the
+ * platform-support matrix, and the two MUST agree or a package could pass the
+ * audit while the CLI fails to find its artifact.
+ *
+ * The direction matters: `${process.platform}-${process.arch}` is what a
+ * running process can compute about itself, so folding *onto* it means the
+ * host identity never has to be translated in the hot path.
  */
 const ARCH_ALIASES = {
-    x64: 'x86_64',
-    amd64: 'x86_64',
-    arm64: 'aarch64',
+    x86_64: 'x64',
+    amd64: 'x64',
+    aarch64: 'arm64',
 };
 /**
- * Canonical `<os>-<arch>` form so `linux-x64` and `linux-x86_64` — or
- * `darwin-arm64` and `darwin-aarch64` — compare equal. Only the *arch* half is
- * normalised; the OS half is always a `process.platform` token
- * (`linux`/`darwin`/`win32`), which has no competing spelling.
+ * Canonical `<os>-<arch>` form — the node spelling — so `linux-x86_64` and
+ * `linux-x64` compare equal. Only the *arch* half is normalised; the OS half
+ * is always a `process.platform` token (`linux`/`darwin`/`win32`), which has
+ * no competing spelling.
  */
 export function canonicalPlatformToken(token) {
     const dash = token.indexOf('-');
@@ -61,36 +70,38 @@ export function canonicalPlatformToken(token) {
 /**
  * The prebuild directory names to probe for a host, most-specific first.
  *
- * There are two live spellings in this repo and neither can be declared the
- * winner:
+ * The canonical name is `${process.platform}-${process.arch}` — `linux-x64`,
+ * `linux-arm64`, `darwin-arm64`, `win32-x64`. Every package in the release
+ * train declares it (`gjsify.platforms`), `scripts/stage-prebuild.mjs` is the
+ * only thing that creates it, and `scripts/audit-runtimes.mjs --check` rejects
+ * any other spelling, so the three can no longer drift.
  *
- *   * the Vala/meson bridges stage `prebuilds/linux-x86_64/` — uname-style,
- *     because the meson jobs name the directory after `uname -m`;
- *   * `@gjsify/node-gi` (and `@gjsify/napi`'s prebuild staging) use
- *     `prebuilds/${process.platform}-${process.arch}/` — node-style
- *     (`linux-x64`, `darwin-arm64`, `win32-x64`).
+ * Two probes remain BEHIND that canonical name, and both are backward
+ * compatibility with tarballs already on npm — not a second convention:
  *
- * So we probe both, and — when the package declares `gjsify.platforms` — we
- * probe the package's OWN spelling first. That is strictly better than
- * guessing: a package that declares `darwin-arm64` tells us the exact
- * directory name it stages, whatever convention it picked.
+ *   1. **The package's own declared spelling.** A tarball published before the
+ *      rename declares (and ships) `linux-x86_64`; probing its declaration
+ *      first loads it without the CLI having to guess. This is also what makes
+ *      the rename work in the OTHER direction — an older CLI resolving a newer
+ *      package — because `canonicalPlatformToken` folds both spellings onto
+ *      one form at both ends.
+ *   2. **The legacy uname spelling.** Only reachable for a package that ships
+ *      a prebuild dir and declares NO `gjsify.platforms` at all — i.e. a
+ *      tarball predating the OS-axis audit, or a third-party package using
+ *      `gjsify.prebuilds` without the declaration. Inside this repo the audit
+ *      makes that state impossible.
  *
- * Ordering of the generic fallbacks is per-OS rather than fixed, so the first
- * probe is the spelling that platform's toolchain actually produces:
- * uname-style on Linux (`linux-x86_64`), node-style on macOS/Windows
- * (`darwin-arm64`, `win32-x64` — on Apple silicon `uname -m` also reports
- * `arm64`, so there node-style *is* the native spelling).
+ * Both are pure array entries matched against an already-read directory
+ * listing — no extra I/O — so tolerance on the READ side costs nothing, while
+ * the single spelling is enforced everywhere a name is WRITTEN.
  *
  * @param platform `process.platform` value.
  * @param arch `process.arch` value.
  * @param declaredPlatforms `package.json#gjsify.platforms`, when present.
  */
 export function prebuildDirCandidates(platform, arch, declaredPlatforms) {
-    const unameArch = NODE_ARCH_TO_UNAME[arch] ?? arch;
-    const preferred = platform === 'linux' ? unameArch : arch;
-    const alternate = platform === 'linux' ? arch : unameArch;
-    const generic = [`${platform}-${preferred}`, `${platform}-${alternate}`];
-    const hostCanonical = canonicalPlatformToken(generic[0]);
+    const canonical = `${platform}-${arch}`;
+    const legacyArch = NODE_ARCH_TO_LEGACY_UNAME[arch] ?? arch;
     const out = [];
     const push = (name) => {
         if (!out.includes(name))
@@ -100,12 +111,13 @@ export function prebuildDirCandidates(platform, arch, declaredPlatforms) {
     for (const declared of declaredPlatforms ?? []) {
         if (typeof declared !== 'string')
             continue;
-        if (canonicalPlatformToken(declared) === hostCanonical)
+        if (canonicalPlatformToken(declared) === canonical)
             push(declared);
     }
-    // 2. The two generic spellings.
-    for (const name of generic)
-        push(name);
+    // 2. The canonical node spelling — what everything in the train stages.
+    push(canonical);
+    // 3. The legacy uname spelling, for undeclared pre-rename tarballs.
+    push(`${platform}-${legacyArch}`);
     return out;
 }
 /**

package/lib/utils/gjs-bundle-guard.d.ts

@@ -0,0 +1,32 @@
+/** The one bundler-output field this guard needs, from either engine. */
+export interface GuardedChunk {
+    /** Emitted chunk name, for the error message. */
+    fileName?: string;
+    /** External specifiers the chunk STATICALLY imports (rollup/rolldown contract). */
+    imports?: readonly string[];
+}
+/**
+ * Bare `node:` specifiers a `--app gjs` bundle may keep as static imports.
+ *
+ * Deliberately EMPTY. Every Node builtin has an `@gjsify/*` polyfill that
+ * `--app gjs` aliases to, so there is no specifier that both survives into the
+ * module graph and loads under GJS. Reading the graph instead of the text is
+ * what keeps this list empty — the entries an earlier text-scanning version
+ * needed (`node:module`, `node:process`) were quoted lookalikes, never imports.
+ *
+ * Add an entry ONLY with a comment naming why GJS can resolve it. Each one is a
+ * specifier this guard can no longer catch for real.
+ */
+export declare const GJS_ALLOWED_NODE_IMPORTS: readonly string[];
+/**
+ * The distinct bare `node:` specifiers `chunks` statically import, minus the
+ * allowlist. Sorted, so the error message and any test are stable.
+ */
+export declare function findDisallowedNodeImports(chunks: readonly GuardedChunk[], allowed?: readonly string[]): string[];
+/**
+ * Throw when a built `--app gjs` bundle statically imports Node builtins.
+ *
+ * @param chunks   the emitted chunks, as reported by the bundler
+ * @param outfile  path of the bundle, for the error message
+ */
+export declare function assertGjsBundleLoadable(chunks: readonly GuardedChunk[], outfile: string): void;

package/lib/utils/gjs-bundle-guard.js

@@ -0,0 +1,103 @@
+// Build-time guard: a `--app gjs` bundle must not keep bare `node:` imports.
+//
+// Stock GJS has NO `node:` module loader. A single surviving
+// `import … from "node:fs"` makes it abort the ENTIRE module graph before one
+// line executes:
+//
+//   Gjs-WARNING **: JS ERROR: ImportError: Unsupported URI scheme for importing: node
+//   Gjs-CRITICAL **: Failed to resolve imports for module: '…/dist/cli.gjs.mjs'
+//
+// `--app gjs` maps every Node builtin to its `@gjsify/*` polyfill, so a healthy
+// bundle has ZERO of them. But when an alias TARGET cannot be resolved — the
+// classic case being a workspace checkout whose `@gjsify/*` packages have no
+// built `lib/`, so `exports["."]` points at a file that does not exist — the
+// bundler falls back to treating the import as external and re-emits the
+// ORIGINAL `node:*` specifier. That is a WARNING, not an error: the build
+// "succeeds" and writes a bundle that cannot load anywhere. It cost three red
+// CI jobs to notice, because nothing between `gjsify build` and CI ever
+// executes the emitted GJS bundle (tsc, lint, format and the unit/e2e suites
+// all run the Node entry).
+//
+// The pre-commit hook makes it worse rather than better: it rebuilds and
+// AUTO-STAGES `dist/cli.gjs.mjs`, so a developer whose checkout cannot resolve
+// the polyfills commits a broken artifact without ever seeing it.
+//
+// So the refusal belongs at build time, in `gjsify build --app gjs` itself —
+// not in a git hook and not in one package's `build:gjs-bundle` script. The
+// invariant is a property of the ARTIFACT, and every showcase, every downstream
+// app (buchhaltung, bauplaner, Learn6502) and CI all produce it through this
+// one code path. A hook would protect only commits in this repo; a per-package
+// script would protect one package.
+//
+// ## The oracle is the module graph, NOT the emitted text
+//
+// The first cut of this guard grepped the output for `from "node:…"`. That is
+// wrong, and CI caught it: `@gjsify/process`'s own test bundle names a case
+//
+//   await it(`named-import hrtime (from "node:process") preserves .bigint`, …)
+//
+// so the phrase appears verbatim inside a STRING, in a bundle that loads and
+// runs under GJS perfectly well. The same trap sits in `@gjsify/cli`'s own
+// bundle, which embeds `giNodeShimSource()`'s `--app node` codegen template
+// (`import { createRequire } from 'node:module';`). Telling a statement from a
+// quoted lookalike needs a JS lexer — but the bundler already did that work:
+// every chunk carries the list of external specifiers it actually imports. That
+// list is exact, engine-independent (npm `rolldown` returns it directly,
+// `@gjsify/rolldown-native` forwards it through `synthRolldownOutput`), and
+// free.
+//
+// Scope is STATIC imports, which is precisely the failure mode above: they are
+// resolved when GJS links the module, so one bad specifier kills the whole
+// bundle. A dynamic `import('node:x')` throws lazily at its call site instead —
+// a real bug, but not "the artifact cannot load", and not what this gate is
+// for.
+/**
+ * Bare `node:` specifiers a `--app gjs` bundle may keep as static imports.
+ *
+ * Deliberately EMPTY. Every Node builtin has an `@gjsify/*` polyfill that
+ * `--app gjs` aliases to, so there is no specifier that both survives into the
+ * module graph and loads under GJS. Reading the graph instead of the text is
+ * what keeps this list empty — the entries an earlier text-scanning version
+ * needed (`node:module`, `node:process`) were quoted lookalikes, never imports.
+ *
+ * Add an entry ONLY with a comment naming why GJS can resolve it. Each one is a
+ * specifier this guard can no longer catch for real.
+ */
+export const GJS_ALLOWED_NODE_IMPORTS = [];
+/**
+ * The distinct bare `node:` specifiers `chunks` statically import, minus the
+ * allowlist. Sorted, so the error message and any test are stable.
+ */
+export function findDisallowedNodeImports(chunks, allowed = GJS_ALLOWED_NODE_IMPORTS) {
+    const found = new Set();
+    for (const chunk of chunks) {
+        for (const specifier of chunk.imports ?? []) {
+            if (!specifier.startsWith('node:'))
+                continue;
+            if (allowed.includes(specifier))
+                continue;
+            found.add(specifier);
+        }
+    }
+    return [...found].sort();
+}
+/**
+ * Throw when a built `--app gjs` bundle statically imports Node builtins.
+ *
+ * @param chunks   the emitted chunks, as reported by the bundler
+ * @param outfile  path of the bundle, for the error message
+ */
+export function assertGjsBundleLoadable(chunks, outfile) {
+    const offenders = findDisallowedNodeImports(chunks);
+    if (offenders.length === 0)
+        return;
+    throw new Error(`gjsify build --app gjs: ${outfile} still imports ${offenders.length} bare \`node:\` module(s), ` +
+        'which stock GJS cannot resolve — it would fail at load with ' +
+        '"ImportError: Unsupported URI scheme for importing: node".\n' +
+        offenders.map((s) => `  - ${s}`).join('\n') +
+        '\n\nThese should have been aliased to their `@gjsify/*` polyfills. The usual cause is that the ' +
+        'alias TARGET could not be resolved, so the bundler externalised the import instead (look for ' +
+        'UNRESOLVED_IMPORT warnings above): e.g. a workspace checkout whose `@gjsify/*` packages have no ' +
+        'built `lib/`. Build the workspace first (`gjsify run build:infra`), or fix the resolution, then ' +
+        'rebuild.');
+}

package/lib/utils/oxc-resolve.js

@@ -46,7 +46,7 @@
 // lives in the Node launcher, so a native oxlint bridge could only run the
 // Rust rule subset. Lint stays Node-spawned until that trade-off is decided
 // (tracked in STATUS.md Open TODOs).
-import { existsSync, readFileSync } from 'node:fs';
+import { existsSync, readFileSync, readdirSync } from 'node:fs';
 import { join, resolve } from 'node:path';
 import { createRequire } from 'node:module';
 import { pathToFileURL } from 'node:url';
@@ -89,7 +89,12 @@ function oxcBindingSuffix() {
         // glibc systems have `/lib/ld-linux-*`, musl has `/lib/ld-musl-*`.
         let libc = 'gnu';
         try {
-            const { readdirSync } = require('node:fs');
+            // `readdirSync` is imported STATICALLY at the top of this file. It
+            // used to be a lazy `require('node:fs')` inside this try — a bare
+            // `require` in an ESM module, so it threw ReferenceError, the catch
+            // below swallowed it, and `libc` silently stayed 'gnu': a musl host
+            // would be told to install the WRONG binding package. Same defect
+            // class as commands/affected.ts, and even quieter.
             const libEntries = readdirSync('/lib');
             if (libEntries.some((e) => e.startsWith('ld-musl-'))) {
                 libc = 'musl';

package/lib/utils/run-node.d.ts

@@ -6,6 +6,22 @@ import { type ExampleRuntime } from './runtimes.js';
  * not available under the GJS-bundled CLI.
  */
 export declare function resolveNodeGi(startDir: string): string | null;
+/**
+ * Resolve `@gjsify/node-gi` for a bundle we are about to launch: from the
+ * BUNDLE's own directory first, then from `cwd`.
+ *
+ * The bundle's directory is the correct base and cwd is the fallback, for the
+ * same reason {@link computeNativeEnvForBundle} walks both: `@gjsify/node-gi` is
+ * kept EXTERNAL, so what has to be satisfiable is the RUNTIME's resolution of a
+ * bare specifier from inside the bundle — which Node performs relative to the
+ * importing file, never relative to cwd. A dlx-cache layout
+ * (`~/.cache/gjsify/dlx/<sha>/node_modules/<pkg>/dist/bundle.mjs`) has node-gi
+ * sitting right beside the bundle and nothing at all under the user's cwd, so a
+ * cwd-only probe rejected a run that would have worked. The cwd probe is kept
+ * because a project-local `node_modules` legitimately satisfies a bundle built
+ * into a `dist/` outside it (a `--outfile /tmp/…` build from a project root).
+ */
+export declare function resolveNodeGiForBundle(bundlePath: string, cwd: string): string | null;
 /** Pick the node executable: the current one when on Node, else PATH `node`. */
 export declare function nodeBinary(): string;
 export interface RunNodeBundleOptions {

package/lib/utils/run-node.js

@@ -5,10 +5,12 @@
 // through `@gjsify/node-gi` (the Axis-5 reverse bridge). Two things have to be
 // true at runtime:
 //
-//   1. `@gjsify/node-gi` must resolve from the project — it is kept EXTERNAL by
-//      the bundler (a native addon), so it has to physically exist in the
-//      consumer's node_modules. We verify this up front and emit a clear hint
-//      instead of letting Node throw `ERR_MODULE_NOT_FOUND` deep in the bundle.
+//   1. `@gjsify/node-gi` must resolve FROM THE BUNDLE — it is kept EXTERNAL by
+//      the bundler (a native addon), so it has to physically exist in a
+//      node_modules the bundle's own directory can reach (that is where Node
+//      will look), with the CWD as a fallback. We verify this up front and emit
+//      a clear hint instead of letting Node throw `ERR_MODULE_NOT_FOUND` deep in
+//      the bundle. See `resolveNodeGiForBundle`.
 //   2. `gi://Gtk` / `gi://Adw` etc. must resolve. System typelibs come from the
 //      default GI search path, but any `@gjsify/*` Vala bridge a story pulls in
 //      ships its typelib in `prebuilds/` — so we reuse the SAME
@@ -21,7 +23,7 @@
 // `gjs`, which cannot run a `--app node` bundle).
 import { spawn } from 'node:child_process';
 import { existsSync, readFileSync } from 'node:fs';
-import { join, resolve } from 'node:path';
+import { dirname, join, resolve } from 'node:path';
 import { isNode } from '@gjsify/rolldown-plugin-gjsify/runtime';
 import { computeNativeEnvForBundle } from './run-gjs.js';
 import { RUNTIMES } from './runtimes.js';
@@ -43,6 +45,25 @@ export function resolveNodeGi(startDir) {
         dir = parent;
     }
 }
+/**
+ * Resolve `@gjsify/node-gi` for a bundle we are about to launch: from the
+ * BUNDLE's own directory first, then from `cwd`.
+ *
+ * The bundle's directory is the correct base and cwd is the fallback, for the
+ * same reason {@link computeNativeEnvForBundle} walks both: `@gjsify/node-gi` is
+ * kept EXTERNAL, so what has to be satisfiable is the RUNTIME's resolution of a
+ * bare specifier from inside the bundle — which Node performs relative to the
+ * importing file, never relative to cwd. A dlx-cache layout
+ * (`~/.cache/gjsify/dlx/<sha>/node_modules/<pkg>/dist/bundle.mjs`) has node-gi
+ * sitting right beside the bundle and nothing at all under the user's cwd, so a
+ * cwd-only probe rejected a run that would have worked. The cwd probe is kept
+ * because a project-local `node_modules` legitimately satisfies a bundle built
+ * into a `dist/` outside it (a `--outfile /tmp/…` build from a project root).
+ */
+export function resolveNodeGiForBundle(bundlePath, cwd) {
+    const resolvedBundle = resolve(bundlePath);
+    return resolveNodeGi(dirname(resolvedBundle)) ?? resolveNodeGi(cwd);
+}
 /** Pick the node executable: the current one when on Node, else PATH `node`. */
 export function nodeBinary() {
     return isNode() && process.execPath ? process.execPath : 'node';
@@ -55,7 +76,7 @@ export function nodeBinary() {
  */
 export async function runNodeBundle(bundlePath, extraArgs = [], options = {}) {
     const cwd = process.cwd();
-    if (!resolveNodeGi(cwd)) {
+    if (!resolveNodeGiForBundle(bundlePath, cwd)) {
         throw new Error('Cannot run the storybook on Node: `@gjsify/node-gi` is not installed.\n' +
             'Add @gjsify/node-gi as a dependency to run the storybook on Node, e.g.:\n' +
             '  "devDependencies": { "@gjsify/node-gi": "^0.13.0" }');
@@ -113,7 +134,7 @@ export function bundleRequiresNodeGi(bundlePath) {
 export async function runRuntimeBundle(runtime, bundlePath, extraArgs = [], options = {}) {
     const cwd = process.cwd();
     const resolvedBundle = resolve(bundlePath);
-    if (bundleRequiresNodeGi(resolvedBundle) && !resolveNodeGi(cwd)) {
+    if (bundleRequiresNodeGi(resolvedBundle) && !resolveNodeGiForBundle(resolvedBundle, cwd)) {
         throw new Error(`Cannot run this bundle on ${runtime}: it uses gi:// via \`@gjsify/node-gi\`, which is not installed.\n` +
             'Add @gjsify/node-gi as a dependency to run gi:// code off GJS, e.g.:\n' +
             '  "dependencies": { "@gjsify/node-gi": "^0.13.0" }');

package/lib/utils/runtimes.d.ts

@@ -37,6 +37,27 @@ export declare function isRuntimeOnPath(probe: string): boolean;
 export declare function isRuntimeAvailable(runtime: ExampleRuntime): boolean;
 /** Which of gjs/node/bun/deno are runnable on this host. */
 export declare function availableRuntimes(): ExampleRuntime[];
+/**
+ * The default `--runtime` for running a prebuilt EXAMPLE/SHOWCASE: `gjs`
+ * whenever gjs is runnable here, else the host runtime.
+ *
+ * This is deliberately NOT a plain `hostRuntime()`. A showcase's canonical
+ * artifact is its `--app gjs` bundle (`gjsify.main`) — that is what every
+ * showcase ships, what the `gjs` path installs via `gjsify dlx`, and what the
+ * docs call the default. Following the host instead means `npx @gjsify/cli
+ * showcase <name>` (host = node) silently asks for the `--app node` bundle,
+ * which most showcases do not ship and which additionally needs
+ * `@gjsify/node-gi` in the consumer's project — so the FIRST-RUN experience of
+ * the primary documented entry point failed on a missing file.
+ *
+ * Same rule `gjsify run` already applies in its bare-file path, where a
+ * `--app gjs` bundle stays on gjs regardless of host (`isLikelyGjsBundle`);
+ * here the "is it a gjs artifact" question is answered by the command instead
+ * of by sniffing the file. `--runtime` still overrides explicitly, and a host
+ * WITHOUT gjs (a plain Node/bun/deno box) keeps following the host so the
+ * node-capable showcases stay runnable there.
+ */
+export declare function defaultExampleRuntime(): ExampleRuntime;
 interface ExampleGjsifyField {
     example?: {
         runtimes?: unknown;

package/lib/utils/runtimes.js

@@ -64,6 +64,29 @@ export function isRuntimeAvailable(runtime) {
 export function availableRuntimes() {
     return EXAMPLE_RUNTIMES.filter((rt) => isRuntimeAvailable(rt));
 }
+/**
+ * The default `--runtime` for running a prebuilt EXAMPLE/SHOWCASE: `gjs`
+ * whenever gjs is runnable here, else the host runtime.
+ *
+ * This is deliberately NOT a plain `hostRuntime()`. A showcase's canonical
+ * artifact is its `--app gjs` bundle (`gjsify.main`) — that is what every
+ * showcase ships, what the `gjs` path installs via `gjsify dlx`, and what the
+ * docs call the default. Following the host instead means `npx @gjsify/cli
+ * showcase <name>` (host = node) silently asks for the `--app node` bundle,
+ * which most showcases do not ship and which additionally needs
+ * `@gjsify/node-gi` in the consumer's project — so the FIRST-RUN experience of
+ * the primary documented entry point failed on a missing file.
+ *
+ * Same rule `gjsify run` already applies in its bare-file path, where a
+ * `--app gjs` bundle stays on gjs regardless of host (`isLikelyGjsBundle`);
+ * here the "is it a gjs artifact" question is answered by the command instead
+ * of by sniffing the file. `--runtime` still overrides explicitly, and a host
+ * WITHOUT gjs (a plain Node/bun/deno box) keeps following the host so the
+ * node-capable showcases stay runnable there.
+ */
+export function defaultExampleRuntime() {
+    return isRuntimeAvailable('gjs') ? 'gjs' : hostRuntime();
+}
 /**
  * Read a package's declared example runtimes. Returns the (validated) list, or
  * `null` when the package declares none — the "unconstrained / permissive" case.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@gjsify/cli",
-    "version": "0.23.0",
+    "version": "0.24.1",
     "description": "CLI for Gjsify",
     "type": "module",
     "main": "lib/index.js",
@@ -130,19 +130,19 @@
         "cli"
     ],
     "dependencies": {
-        "@gjsify/buffer": "^0.23.0",
-        "@gjsify/create-app": "^0.23.0",
-        "@gjsify/node-globals": "^0.23.0",
-        "@gjsify/node-polyfills": "^0.23.0",
-        "@gjsify/npm-registry": "^0.23.0",
-        "@gjsify/resolve-npm": "^0.23.0",
-        "@gjsify/rolldown-plugin-gjsify": "^0.23.0",
-        "@gjsify/rolldown-plugin-pnp": "^0.23.0",
-        "@gjsify/semver": "^0.23.0",
-        "@gjsify/tar": "^0.23.0",
-        "@gjsify/tsc": "^0.23.0",
-        "@gjsify/web-polyfills": "^0.23.0",
-        "@gjsify/workspace": "^0.23.0",
+        "@gjsify/buffer": "^0.24.1",
+        "@gjsify/create-app": "^0.24.1",
+        "@gjsify/node-globals": "^0.24.1",
+        "@gjsify/node-polyfills": "^0.24.1",
+        "@gjsify/npm-registry": "^0.24.1",
+        "@gjsify/resolve-npm": "^0.24.1",
+        "@gjsify/rolldown-plugin-gjsify": "^0.24.1",
+        "@gjsify/rolldown-plugin-pnp": "^0.24.1",
+        "@gjsify/semver": "^0.24.1",
+        "@gjsify/tar": "^0.24.1",
+        "@gjsify/tsc": "^0.24.1",
+        "@gjsify/web-polyfills": "^0.24.1",
+        "@gjsify/workspace": "^0.24.1",
         "cosmiconfig": "^9.0.2",
         "get-tsconfig": "^4.14.0",
         "pkg-types": "^2.3.1",
@@ -150,13 +150,13 @@
         "yargs": "^18.0.0"
     },
     "devDependencies": {
-        "@gjsify/unit": "^0.23.0",
+        "@gjsify/unit": "^0.24.1",
         "@types/yargs": "^17.0.35",
         "typescript": "^6.0.3"
     },
     "peerDependencies": {
-        "@gjsify/oxfmt-native": "^0.23.0",
-        "@gjsify/rolldown-native": "^0.23.0"
+        "@gjsify/oxfmt-native": "^0.24.1",
+        "@gjsify/rolldown-native": "^0.24.1"
     },
     "peerDependenciesMeta": {
         "@gjsify/oxfmt-native": {