@gjsify/cli 0.45.0 → 0.46.0

package/lib/utils/ship/msi.js

@@ -21,7 +21,8 @@
 //   * lays the program directory `windows-dir` produces under
 //     `%ProgramFiles%\<App>`, overridable with `msiexec INSTALLDIR=…`;
 //   * gives the user something to start — one Start-Menu shortcut at the top
-//     level, aimed at the same `.cmd` launcher the zip's user double-clicks;
+//     level, aimed at the GUI-subsystem `.exe` launcher the zip's user
+//     double-clicks (see the last paragraph of this header);
 //   * comes off again: Add/Remove Programs gets its entry from the MSI's own
 //     `ProductName`/`ProductVersion`/`Manufacturer`, and `msiexec /x` removes
 //     every file the package installed. The `windows-dir-selfcontained` leg's
@@ -57,15 +58,20 @@
 //      bought for nothing. A directory whose id is a public property is settable
 //      from a command line either way.
 //
-// AND ONE THING IT DOES NOT FIX. `node.exe` is a CONSOLE-subsystem image and the
-// Node release ships no `nodew.exe` (`status/open-todos.md` carries the offsets),
-// so the shortcut this installer writes pops a console window behind the GUI
-// exactly as the `.cmd` does. Nothing here changes that, and no leg can observe
-// it — every Windows CI leg starts the app from a shell and already has one.
+// AND ONE THING IT USED NOT TO FIX. `node.exe` is a CONSOLE-subsystem image and
+// the Node release ships no `nodew.exe`, so a Start-Menu shortcut to the `.cmd`
+// popped a console window behind the GUI exactly as a double-click did. The
+// shortcut now points at the GUI-subsystem launcher the windows LAYOUT stages
+// (`utils/ship/pe-launcher.ts`), which runs the same `.cmd` with no window —
+// measured on `win11-gjsify` in session 1, where the `.cmd` produces two new
+// visible console-host windows and the `.exe` produces none. Still no CI leg can
+// observe it: every Windows job starts the app from a shell and already has a
+// console.
 import { createHash } from 'node:crypto';
 import { mkdirSync, rmSync, writeFileSync } from 'node:fs';
 import { join, posix } from 'node:path';
 import { describeExit, spawnToCompletion } from '../spawn.js';
+import { windowsGuiLauncherPath } from './layout.js';
 import { xmlEscape } from './xml.js';
 /**
  * The UUID namespace every GUID in a generated `.msi` is derived under.
@@ -236,7 +242,18 @@ export function renderWxs(input) {
     // `Name <email>` is `PackSettings.maintainer`'s shape; ARP shows `Publisher`
     // to a human, and an address in that field reads as a mistake.
     const manufacturer = settings.maintainer.replace(/\s*<[^>]*>\s*$/, '').trim() || settings.maintainer;
-    const launcher = `${settings.binaryName}.cmd`;
+    // THE SHORTCUT POINTS AT THE `.exe`, NOT THE `.cmd` — this installer's half of
+    // the console-window fix. A Start-Menu shortcut to a batch file starts
+    // `cmd.exe`, a console-subsystem image, so Windows allocates a console for it
+    // and a black window sits behind the app (ADR 0024 § M3). The GUI-subsystem
+    // launcher beside it — `utils/ship/pe-launcher.ts`, staged by the windows
+    // LAYOUT — runs the same `.cmd` and has no window of its own.
+    //
+    // Derived from `windowsGuiLauncherPath` and never spelled again here: the stub
+    // finds its `.cmd` by rewriting the last three characters of its own filename,
+    // so the two names are ONE decision, and a second literal is where they would
+    // come apart.
+    const launcher = windowsGuiLauncherPath(settings);
     const identifiers = new Map();
     const claim = (id, what) => {
         const previous = identifiers.get(id);

package/lib/utils/ship/payload.js

@@ -440,7 +440,15 @@ export function assertLauncherMatchesInterpreter(payload, layout, identity, inte
         '    An installed package that depends on one interpreter and runs another installs cleanly and ' +
         'fails\n' +
         "    at first launch, on the user's machine.\n" +
-        `    Either set \`gjsify.app\` to "${other}", or fix the launcher — if it comes from ` +
+        // THIS TARGET's key, and not `gjsify.app`. Since #1486 the runtime is
+        // resolved per target, so sending the reader to the project field to
+        // fix ONE layout's launcher moves every other layout's `Depends:` with
+        // it — the defect § A22 exists to close, reintroduced by the message
+        // that reports it. Named as a project edit because `--from-stage`
+        // reaches here too, and that host has no config to change.
+        `    Either set \`gjsify.ship.app.${layout.os}\` to "${other}" in the project this was staged ` +
+        'from — it overrides\n' +
+        '    `gjsify.app` for that target alone — or fix the launcher: if it comes from ' +
         '`gjsify.ship.extraFiles`,\n' +
         '    that override is what decides which interpreter runs and it must match the declaration.');
 }
@@ -488,19 +496,30 @@ const SHARE_VERDICTS = [
 /**
  * Paths that survive the trip, so the rule below can be an INVERSE one.
  *
- * Two entries and they are different SHAPES, which is why the check below tests
+ * Three entries and they are different SHAPES, which is why the check below tests
  * both containment and equality:
  *
  *  - `share/locale` is a DIRECTORY. A `.mo` is read straight off disk by
  *    `bindtextdomain`, with no install step anywhere, and the launcher hands the
  *    directory over on all three layouts.
+ *  - `share/fonts` is a directory too, and it is here for a NARROWER reason than
+ *    the one next to it (ADR 0038). What this list means is "no package install
+ *    step makes this correct", and that is true of a face on every layout: nothing
+ *    compiles it, nothing reindexes it, and on Linux fontconfig scans the
+ *    directory and caches lazily per user. What it deliberately does NOT claim is
+ *    that a face is FOUND on the other two — macOS reaches it through
+ *    `Info.plist`'s `ATSApplicationFontsPath` and Windows only through a call the
+ *    app makes itself. Those are `Layout.fontGap`, printed separately, because
+ *    they are facts about an OS rather than about a missing scriptlet, and folding
+ *    them in here would report the answer under a heading that names the wrong
+ *    question.
  *  - `gschemas.compiled` is one FILE, and it is here because it is not a cost —
  *    it is the thing that removes one. Reported under a warning headed "whose
  *    Linux correctness comes from a package install step" it would name the fix
  *    as if it were the problem, and it would be the sixth line of a five-line
  *    list nobody asked to grow.
  */
-const SHARE_PORTABLE = [SHARE.locale, SCHEMA_CACHE];
+const SHARE_PORTABLE = [SHARE.locale, SHARE.fonts, SCHEMA_CACHE];
 /**
  * Every `share/` entry a non-Linux layout carries, classified — including the
  * ones nothing here has a rule for.

package/lib/utils/ship/pe-launcher.d.ts

@@ -0,0 +1,29 @@
+/**
+ * `IMAGE_SUBSYSTEM_WINDOWS_GUI` — the one field this whole file exists to set.
+ *
+ * The counterpart is 3, `_CUI`, which is what `node.exe` and `cmd.exe` are and
+ * what makes Windows allocate a console when there is none to inherit.
+ */
+export declare const PE_SUBSYSTEM_GUI = 2;
+/** Where `Subsystem` lands in the emitted image: `e_lfanew` + 4 + 20 + 68. */
+export declare const PE_SUBSYSTEM_OFFSET: number;
+export interface GuiLauncherInput {
+    /**
+     * The file the stub writes the child's output to under `%TEMP%`, when there
+     * is no console to inherit.
+     *
+     * A LEAF and not a path: `%TEMP%` is the one directory a program can write to
+     * on every Windows install, and the program directory is not — `C:\Program
+     * Files\<App>` is read-only for the user who runs the app.
+     */
+    logLeaf: string;
+}
+/**
+ * The GUI-subsystem launcher, as a complete PE32+ image.
+ *
+ * Deterministic: the same input always produces the same bytes, with no
+ * timestamp, no checksum and no build-host string anywhere in the file — which
+ * is what lets `tests/e2e/ship-windows` compare two runs and what keeps the
+ * artifact reproducible for anyone who repacks a stage (ADR 0024 § A2).
+ */
+export declare function buildGuiLauncher(input: GuiLauncherInput): Uint8Array;