@gjsify/cli 0.64.5 → 0.64.7

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

@@ -28,12 +28,14 @@
 // THE CALLER IS `utils/ship/app-runtime.ts` (#1354 M2b), and this paragraph used
 // to say there was none — "⚠️ NOTHING CALLS THIS YET, outside its own spec … a
 // promise to a caller that does not exist yet". It exists: the macOS layout stages
-// `nodePath` into `Contents/MacOS/node` and `licensePath` beside it, and the
-// `null`-not-throw contract is what lets that caller stage the GTK closure it DID
-// find while naming the interpreter package it did not. #1354 M3 adds the second
-// caller — the Windows program directory stages `node.exe` beside its `.cmd` — so
-// both non-Linux rows of the table above are now used, and this paragraph no
-// longer has a "still has none" half to record.
+// `nodePath` into `Contents/Helpers/<display name>` and `licensePath` beside it in
+// `Contents/Resources`, and the `null`-not-throw contract is what lets that caller
+// stage the GTK closure it DID find while naming the interpreter package it did
+// not. #1354 M3 adds the second caller — the Windows program directory stages
+// `node.exe` beside its `.cmd` — so both non-Linux rows of the table above are now
+// used, and this paragraph no longer has a "still has none" half to record.
+// `node.exe` keeps that name verbatim: nothing collides with it on Windows, and
+// only the darwin leaf changed — see `layout.ts`'s `dirs.helpers`.
 //
 // The tests keep the by-name claim honest independently of any caller: they
 // resolve a real installed package out of a throwaway consumer tree holding
@@ -43,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.5",
+    "version": "0.64.7",
     "description": "CLI for Gjsify",
     "type": "module",
     "main": "lib/index.js",
@@ -142,22 +142,22 @@
         "cli"
     ],
     "dependencies": {
-        "@gjsify/blueprint": "^0.64.5",
-        "@gjsify/buffer": "^0.64.5",
-        "@gjsify/create-app": "^0.64.5",
-        "@gjsify/node-globals": "^0.64.5",
-        "@gjsify/node-polyfills": "^0.64.5",
-        "@gjsify/npm-registry": "^0.64.5",
-        "@gjsify/resolve-npm": "^0.64.5",
-        "@gjsify/rolldown-plugin-gjsify": "^0.64.5",
-        "@gjsify/vite-plugin-blueprint": "^0.64.5",
-        "@gjsify/rolldown-plugin-pnp": "^0.64.5",
-        "@gjsify/semver": "^0.64.5",
-        "@gjsify/tar": "^0.64.5",
-        "@gjsify/tsc": "^0.64.5",
-        "@gjsify/utils": "^0.64.5",
-        "@gjsify/web-polyfills": "^0.64.5",
-        "@gjsify/workspace": "^0.64.5",
+        "@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.5",
+        "@gjsify/unit": "^0.64.7",
         "@types/yargs": "^17.0.35",
         "typescript": "^6.0.3"
     },
     "peerDependencies": {
-        "@gjsify/oxfmt-native": "^0.64.5",
-        "@gjsify/rolldown-native": "^0.64.5"
+        "@gjsify/oxfmt-native": "^0.64.7",
+        "@gjsify/rolldown-native": "^0.64.7"
     },
     "peerDependenciesMeta": {
         "@gjsify/oxfmt-native": {