@gjsify/cli 0.64.6 → 0.64.7

package/lib/commands/ship.js

@@ -44,7 +44,7 @@ import { buildFlatpakBundle } from '../utils/ship/flatpak.js';
 import { iconSizes, resolveAppIcon } from '../utils/ship/icons.js';
 import { localizeMetadata } from '../utils/ship/localize-metadata.js';
 import { assertHostCanFinish, assertKindCanPack, assertToolsInstalled, canCarryTicket, configuredFormats, defaultFormatIds, formatIdsFor, resolveFormats, windowsProgramDirName, FORMAT_IDS, FORMATS, } from '../utils/ship/formats.js';
-import { assertLayoutSupportsArch, hostLayout, layoutForOs, place, placeStage, resolveLayout, LAYOUT_NAMES, } from '../utils/ship/layout.js';
+import { assertLayoutSupportsArch, hostLayout, layoutForOs, place, placeStage, resolveLayout, windowsGuiLauncherPath, LAYOUT_NAMES, LAYOUTS, } from '../utils/ship/layout.js';
 import { isNodeRuntimeTarget, resolveNodeRuntime } from '../utils/ship/node-runtime.js';
 import { isUnder, SHARE } from '../utils/ship/share-dirs.js';
 import { compileSchemasForPayload, compileSchemasForStage } from '../utils/ship/schemas.js';
@@ -501,7 +501,17 @@ async function assemble(args) {
     // `packOne` reads it again. That is the price of checking the tree that is
     // shipped rather than the bytes that happen to be in memory, and it is the
     // same reason `readStage` exists at all.
-    assertPayloadMatchesArch(readStage([stageDir], staged), settings.arch);
+    //
+    // ONE NAMED EXEMPTION: the windows GUI-launcher stub is x86-64 machine code
+    // on every windows arch by design (`pe-launcher.ts`'s `MACHINE_AMD64`
+    // comment) — it only `exec`s the sibling `.cmd`, which hands off to the
+    // arch-correct `node.exe` the stage carries, and Windows-on-ARM runs x64
+    // code through Prism for exactly this path. `layout.windows` now emits that
+    // stub unconditionally (it used to skip arm64 entirely), so an arm64 stage
+    // legitimately carries one x64 PE beside its arm64 payload.
+    assertPayloadMatchesArch(readStage([stageDir], staged), settings.arch, {
+        exempt: layout === LAYOUTS.windows ? new Set([windowsGuiLauncherPath(settings)]) : undefined,
+    });
     // What the map carried into a layout that has no install step for it.
     //
     // NOT a warning about this command's output being wrong — the files are the

package/lib/commands/showcase.js

@@ -268,7 +268,7 @@ function resolveLocalShowcaseDir(showcase) {
  */
 function gtkRuntimeSpecs(cliVersion) {
     const target = `${process.platform}-${process.arch}`;
-    const shipped = ['win32-x64', 'darwin-arm64', 'darwin-x64'];
+    const shipped = ['win32-x64', 'win32-arm64', 'darwin-arm64', 'darwin-x64'];
     if (!shipped.includes(target))
         return [];
     const name = `@gjsify/gtk-runtime-${target}`;

package/lib/utils/ship/app-runtime.d.ts

@@ -10,7 +10,7 @@ import type { StagedFile } from './types.js';
  * deriving one from the other would make a future Linux GTK bundle silently imply
  * a bundled Linux interpreter (which `node-runtime.ts` refuses on purpose).
  */
-export declare const GTK_RUNTIME_TARGETS: readonly ["darwin-arm64", "darwin-x64", "win32-x64"];
+export declare const GTK_RUNTIME_TARGETS: readonly ["darwin-arm64", "darwin-x64", "win32-x64", "win32-arm64"];
 export type GtkRuntimeTarget = (typeof GTK_RUNTIME_TARGETS)[number];
 /** Is this `<platform>-<arch>` one of the published GTK-closure targets? */
 export declare function isGtkRuntimeTarget(target: string): target is GtkRuntimeTarget;

package/lib/utils/ship/app-runtime.js

@@ -93,7 +93,7 @@ import { resolveInstalledPackage } from '../resolve-npm-package.js';
  * deriving one from the other would make a future Linux GTK bundle silently imply
  * a bundled Linux interpreter (which `node-runtime.ts` refuses on purpose).
  */
-export const GTK_RUNTIME_TARGETS = ['darwin-arm64', 'darwin-x64', 'win32-x64'];
+export const GTK_RUNTIME_TARGETS = ['darwin-arm64', 'darwin-x64', 'win32-x64', 'win32-arm64'];
 /** Is this `<platform>-<arch>` one of the published GTK-closure targets? */
 export function isGtkRuntimeTarget(target) {
     return GTK_RUNTIME_TARGETS.includes(target);

package/lib/utils/ship/formats.js

@@ -132,23 +132,19 @@ function macosArch(arch, _archIndependent) {
 /**
  * `process.arch` → the name Windows and everything that targets it use.
  *
- * ONE ROW, and it is not caution: there is no arm64 GTK CLOSURE to put on it yet.
- * `wingtk/gvsbuild` publishes no arm64 assets, which is why ADR 0089 builds that
- * prefix from our `gjsify/gvsbuild` fork in CI instead — but what a Windows
- * artifact stages is `@gjsify/gtk-runtime-*`, and the arm64 one is not built, so
- * there is nothing for a Windows/ARM artifact to load (#1117). `Layout.arches`
- * refuses the same value one phase earlier, at stage time, with that reason spelled
- * out; this table is the second half — the one that stops a stage assembled by an
- * older gjsify from acquiring a label here.
+ * TWO ROWS now. `wingtk/gvsbuild` still publishes x64 assets only, but ADR 0089
+ * builds the arm64 GTK prefix from our `gjsify/gvsbuild` fork in CI, and
+ * `@gjsify/gtk-runtime-win32-arm64` + `@gjsify/node-runtime-win32-arm64` exist —
+ * the two packages a Windows/ARM artifact stages (#1117, closed by this row).
  *
- * `x64` maps to itself, and unlike the macOS table that is not a coincidence to be
- * caught later: `x64` is the spelling Node's own release archives use
- * (`node-v24.20.0-win-x64.zip`), the spelling gvsbuild's assets use
- * (`GTK4_Gvsbuild_<v>_x64.zip`), and the spelling a `windows-latest x64` runner
- * label uses. `%PROCESSOR_ARCHITECTURE%` says `AMD64` and nothing a user downloads
- * is named after it.
+ * `x64` and `arm64` map to themselves, and unlike the macOS table that is not a
+ * coincidence to be caught later: both are the spelling Node's own release
+ * archives use (`node-v24.20.0-win-{x64,arm64}.zip`), the spelling a
+ * `windows-11-arm` runner's architecture is, and the spelling `--arch` already
+ * accepts everywhere else in this command. `%PROCESSOR_ARCHITECTURE%` says
+ * `AMD64`/`ARM64` and nothing a user downloads is named after that spelling.
  */
-const WINDOWS_ARCH = { x64: 'x64' };
+const WINDOWS_ARCH = { x64: 'x64', arm64: 'arm64' };
 function windowsArch(arch, _archIndependent) {
     return lookupArch(WINDOWS_ARCH, arch, 'Windows');
 }

package/lib/utils/ship/layout.js

@@ -481,39 +481,40 @@ export const LAYOUTS = {
             required: true,
         },
         metadata: (input) => {
+            // Unconditional on `input.arch` — see `pe-launcher.ts`'s `MACHINE_AMD64`
+            // comment for why: the stub is x86-64 machine code on EVERY windows arch,
+            // because all it does is `exec` the sibling `.cmd`, which hands off to the
+            // native `node.exe` the layout staged for that arch. This used to read
+            // `input.arch === 'x64'`, which silently emitted NO launcher stub — and
+            // therefore no icon and no `.exe` for the MSI shortcut to point at — on
+            // arm64, the one arch `arches.only` now admits besides x64.
             const icon = iconFor(input, 'windows');
-            return input.arch === 'x64'
-                ? [
-                    {
-                        path: windowsGuiLauncherPath(input),
-                        mode: 0o755,
-                        source: {
-                            kind: 'bytes',
-                            data: buildGuiLauncher({
-                                logLeaf: windowsLaunchLogLeaf(input),
-                                ...(icon === undefined ? {} : { icon: iconResources(icon) }),
-                            }),
-                        },
+            return [
+                {
+                    path: windowsGuiLauncherPath(input),
+                    mode: 0o755,
+                    source: {
+                        kind: 'bytes',
+                        data: buildGuiLauncher({
+                            logLeaf: windowsLaunchLogLeaf(input),
+                            ...(icon === undefined ? {} : { icon: iconResources(icon) }),
+                        }),
                     },
-                ]
-                : [];
+                },
+            ];
         },
-        // ONE, and the blocker is OURS now. `wingtk/gvsbuild` hardcodes
-        // `self.platform = "x64"` and publishes x64 assets only — but we stopped
-        // waiting for it: ADR 0089 builds the arm64 GTK prefix from
-        // `gjsify/gvsbuild` in our own CI and `@gjsify/node-gi` declares
-        // `win32-arm64` against it (#2003). What is missing is
-        // `@gjsify/gtk-runtime-win32-arm64`, the closure this layout stages and on
-        // Windows the only GTK there is, so a Windows/ARM artifact still has
-        // nothing to load. Adding arm64 to `only` is the PR that builds that
-        // package, not this one.
+        // TWO now. `wingtk/gvsbuild` still hardcodes `self.platform = "x64"` and
+        // publishes x64 assets only, but ADR 0089 builds the arm64 GTK prefix from
+        // our `gjsify/gvsbuild` fork in CI, `@gjsify/node-gi` ships a win32-arm64
+        // prebuild against it (#2003), and `@gjsify/gtk-runtime-win32-arm64` +
+        // `@gjsify/node-runtime-win32-arm64` now exist — the two packages this
+        // layout stages. Tracked in gjsify/gjsify#1117; remaining gaps (gstsoup,
+        // webgl, gamepad, WebView2 on arm64) are `status/open-todos/windows.md`
+        // § win32-arm64, not a reason to withhold the architecture.
         arches: {
-            only: ['x64'],
-            why: 'the arm64 GTK closure `@gjsify/gtk-runtime-win32-arm64` does not exist yet — the prefix it ' +
-                'would be built from is no longer missing, because ADR 0089 builds it from our `gjsify/gvsbuild` ' +
-                'fork in CI and `@gjsify/node-gi` ships a win32-arm64 prebuild against it — so what is left is ' +
-                'the runtime package this layout would stage, ordered in `status/open-todos/windows.md` and ' +
-                'tracked in gjsify/gjsify#1117',
+            only: ['x64', 'arm64'],
+            why: 'win32 runs on x64 natively and on arm64 via the MSVC closure ADR 0089 builds — both have a ' +
+                '`@gjsify/gtk-runtime-win32-*` and `@gjsify/node-runtime-win32-*` to stage',
         },
     },
 };

package/lib/utils/ship/msi.js

@@ -34,8 +34,15 @@
 // answer:
 //
 //   1. `wixl -a x64` sets Component `Attributes` to 256 — `msidbComponent-
-//      Attributes64bit` — on its own, so `Win64="yes"` is neither written here nor
-//      needed on either backend (`candle -arch x64` does the same).
+//      Attributes64bit` — on its own, so `Win64="yes"` was not written here at
+//      first. ADR 0089 (win32-arm64) is what reopened the question: wixl's own
+//      source sets that bit only for `Arch.X64`/`Arch.IA64`, never for
+//      `Arch.ARM64` (`tools/wixl/builder.vala`), so an unmodified `-a arm64`
+//      build would have shipped a 32-bit component tree. `Win64` is now written
+//      explicitly for every non-x86 arch, on both backends — a Component whose
+//      bitness depends on which backend's inference happens to cover it is
+//      exactly the kind of divergence this file's whole design (one `.wxs`, two
+//      readers) exists to prevent.
 //   2. An ABSOLUTE `Source=` resolves — and this file writes RELATIVE ones anyway,
 //      which is the measurement changing a decision rather than confirming it. The
 //      SAME document is compiled twice, on two machines: `wixl` here and WiX v3 on
@@ -240,6 +247,16 @@ function directoryTree(files) {
  */
 export function renderWxs(input) {
     const { settings, programDirName, archLabel } = input;
+    // EXPLICIT, not inferred — measured against msitools' own source
+    // (tools/wixl/builder.vala, `compileComponent`): `wixl -a <arch>` sets the
+    // `msidbComponentAttributes64bit` bit itself ONLY for `Arch.X64` and
+    // `Arch.IA64`; `Arch.ARM64` falls through and the component stays 32-bit
+    // unless `Win64="yes"` is written here. `candle -arch arm64` (WiX v3.14,
+    // the win32 backend) is not re-verified the same way, so this file no
+    // longer trusts EITHER backend's default for a non-x86 architecture — a
+    // Component silently installing into `%ProgramFiles(x86)%` is the wrong
+    // kind of thing to find out by running the artifact.
+    const win64 = archLabel !== 'x86';
     const productVersion = msiProductVersion(settings.version);
     // `Name <email>` is `PackSettings.maintainer`'s shape; ARP shows `Publisher`
     // to a human, and an address in that field reads as a mistake.
@@ -298,7 +315,7 @@ export function renderWxs(input) {
             // not the authority for it — a Windows packing host would otherwise
             // split a name containing a backslash.
             const name = xmlEscape(posix.basename(file.path));
-            lines.push(`${indent}<Component Id="${componentId}" Guid="${guid}">`);
+            lines.push(`${indent}<Component Id="${componentId}" Guid="${guid}" Win64="${win64 ? 'yes' : 'no'}">`);
             // THE SHORTCUT LIVES IN THE LAUNCHER'S OWN COMPONENT, nested in its
             // `<File>` and advertised. The obvious alternative — a second component
             // under `ProgramMenuFolder` whose key path is an HKCU registry value —

package/lib/utils/ship/node-runtime.d.ts

@@ -1,5 +1,5 @@
 /** The targets a bundled interpreter is published for. */
-export declare const NODE_RUNTIME_TARGETS: readonly ["darwin-arm64", "darwin-x64", "win32-x64"];
+export declare const NODE_RUNTIME_TARGETS: readonly ["darwin-arm64", "darwin-x64", "win32-x64", "win32-arm64"];
 export type NodeRuntimeTarget = (typeof NODE_RUNTIME_TARGETS)[number];
 /** Is this `<platform>-<arch>` one of the published targets? */
 export declare function isNodeRuntimeTarget(target: string): target is NodeRuntimeTarget;

package/lib/utils/ship/node-runtime.js

@@ -45,7 +45,7 @@ import { existsSync } from 'node:fs';
 import { dirname, join } from 'node:path';
 import { resolveInstalledPackage } from '../resolve-npm-package.js';
 /** The targets a bundled interpreter is published for. */
-export const NODE_RUNTIME_TARGETS = ['darwin-arm64', 'darwin-x64', 'win32-x64'];
+export const NODE_RUNTIME_TARGETS = ['darwin-arm64', 'darwin-x64', 'win32-x64', 'win32-arm64'];
 /** Is this `<platform>-<arch>` one of the published targets? */
 export function isNodeRuntimeTarget(target) {
     return NODE_RUNTIME_TARGETS.includes(target);

package/lib/utils/ship/payload.d.ts

@@ -275,7 +275,9 @@ export declare function readBinaryArch(data: Uint8Array): string | null;
  * JavaScript and ADR 0024 § A1 turns it into a design commitment — so a host
  * comparison would refuse the very case the split exists to allow.
  */
-export declare function assertPayloadMatchesArch(payload: readonly PayloadEntry[], arch: string): void;
+export declare function assertPayloadMatchesArch(payload: readonly PayloadEntry[], arch: string, options?: {
+    exempt?: ReadonlySet<string>;
+}): void;
 /**
  * Which executable format these bytes are, or `null` for anything else.
  *

package/lib/utils/ship/payload.js

@@ -767,11 +767,21 @@ export function readBinaryArch(data) {
  * JavaScript and ADR 0024 § A1 turns it into a design commitment — so a host
  * comparison would refuse the very case the split exists to allow.
  */
-export function assertPayloadMatchesArch(payload, arch) {
+export function assertPayloadMatchesArch(payload, arch, options = {}) {
     for (const entry of payload) {
         const found = readBinaryArch(entry.data);
         if (found === null || found === arch)
             continue;
+        // ONE NAMED EXCEPTION, not a relaxation of the rule: the windows layout's
+        // GUI-launcher stub (`pe-launcher.ts`) is x86-64 machine code on every
+        // windows arch BY DESIGN — it only `exec`s the sibling `.cmd`, which hands
+        // off to the arch-correct `node.exe` the stage actually carries, and
+        // Windows-on-ARM runs x64 code through Prism for exactly this reason. The
+        // caller names that one path; nothing else may match it, so a real
+        // cross-arch payload (the #1354/0.41.0 incident this function exists for)
+        // still throws.
+        if (options.exempt?.has(entry.path))
+            continue;
         throw new Error(`gjsify ship: the payload is ${found}, but the package would be labelled ${arch} — ` +
             `${entry.path} is built for ${found}.\n` +
             '    `--arch` names the architecture the PAYLOAD was built for; it does not cross-compile ' +

package/lib/utils/ship/pe-launcher.js

@@ -76,7 +76,17 @@ import { RT_GROUP_ICON, RT_ICON } from './ico.js';
 export const PE_SUBSYSTEM_GUI = 2;
 /** Where `Subsystem` lands in the emitted image: `e_lfanew` + 4 + 20 + 68. */
 export const PE_SUBSYSTEM_OFFSET = 0x80 + 4 + 20 + 68;
-/** `IMAGE_FILE_HEADER.Machine` for x86-64. The only architecture the windows layout has. */
+/**
+ * `IMAGE_FILE_HEADER.Machine` for x86-64 — ALWAYS, even when `windows-dir` is staged for
+ * `--arch arm64` (ADR 0089). This stub does nothing an arm64 build needs a native image for: it
+ * `exec`s the sibling `.cmd`, which Windows resolves to the NATIVE `cmd.exe` either way (no path
+ * is given, so it comes off `System32`, and win32-on-arm64 keeps a native `cmd.exe` beside the
+ * emulated one), and that `.cmd` starts the staged `node.exe` — the arm64 build's OWN interpreter,
+ * never this stub's architecture. So the one thing a second, ARM64-native stub would buy is
+ * skipping Prism's x86-64 emulation for the ~550 bytes THIS image executes before handing off —
+ * a second machine-code emitter, a second `.rsrc` builder and a second `pei-aarch64` reader in
+ * `pe-launcher.spec.ts`, to save microseconds on a path that ends in a process handoff anyway.
+ */
 const MACHINE_AMD64 = 0x8664;
 /** Where the PE signature starts. MSVC emits 0x78; nothing reads the value except through `e_lfanew`. */
 const PE_OFFSET = 0x80;

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@gjsify/cli",
-    "version": "0.64.6",
+    "version": "0.64.7",
     "description": "CLI for Gjsify",
     "type": "module",
     "main": "lib/index.js",
@@ -142,22 +142,22 @@
         "cli"
     ],
     "dependencies": {
-        "@gjsify/blueprint": "^0.64.6",
-        "@gjsify/buffer": "^0.64.6",
-        "@gjsify/create-app": "^0.64.6",
-        "@gjsify/node-globals": "^0.64.6",
-        "@gjsify/node-polyfills": "^0.64.6",
-        "@gjsify/npm-registry": "^0.64.6",
-        "@gjsify/resolve-npm": "^0.64.6",
-        "@gjsify/rolldown-plugin-gjsify": "^0.64.6",
-        "@gjsify/vite-plugin-blueprint": "^0.64.6",
-        "@gjsify/rolldown-plugin-pnp": "^0.64.6",
-        "@gjsify/semver": "^0.64.6",
-        "@gjsify/tar": "^0.64.6",
-        "@gjsify/tsc": "^0.64.6",
-        "@gjsify/utils": "^0.64.6",
-        "@gjsify/web-polyfills": "^0.64.6",
-        "@gjsify/workspace": "^0.64.6",
+        "@gjsify/blueprint": "^0.64.7",
+        "@gjsify/buffer": "^0.64.7",
+        "@gjsify/create-app": "^0.64.7",
+        "@gjsify/node-globals": "^0.64.7",
+        "@gjsify/node-polyfills": "^0.64.7",
+        "@gjsify/npm-registry": "^0.64.7",
+        "@gjsify/resolve-npm": "^0.64.7",
+        "@gjsify/rolldown-plugin-gjsify": "^0.64.7",
+        "@gjsify/vite-plugin-blueprint": "^0.64.7",
+        "@gjsify/rolldown-plugin-pnp": "^0.64.7",
+        "@gjsify/semver": "^0.64.7",
+        "@gjsify/tar": "^0.64.7",
+        "@gjsify/tsc": "^0.64.7",
+        "@gjsify/utils": "^0.64.7",
+        "@gjsify/web-polyfills": "^0.64.7",
+        "@gjsify/workspace": "^0.64.7",
         "acorn": "^8.17.0",
         "cosmiconfig": "^9.0.2",
         "get-tsconfig": "^4.14.0",
@@ -166,13 +166,13 @@
         "yargs": "^18.0.0"
     },
     "devDependencies": {
-        "@gjsify/unit": "^0.64.6",
+        "@gjsify/unit": "^0.64.7",
         "@types/yargs": "^17.0.35",
         "typescript": "^6.0.3"
     },
     "peerDependencies": {
-        "@gjsify/oxfmt-native": "^0.64.6",
-        "@gjsify/rolldown-native": "^0.64.6"
+        "@gjsify/oxfmt-native": "^0.64.7",
+        "@gjsify/rolldown-native": "^0.64.7"
     },
     "peerDependenciesMeta": {
         "@gjsify/oxfmt-native": {