@gjsify/cli 0.50.0 → 0.51.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -32,10 +32,11 @@ import { buildDeb } from '../utils/ship/deb.js';
32
32
  import { deriveDepends, warnAboutGjsFloor, warnAboutNodeFloor } from '../utils/ship/depends.js';
33
33
  import { isGtkRuntimeTarget, stageAppRuntime } from '../utils/ship/app-runtime.js';
34
34
  import { discoverPayload } from '../utils/ship/discover.js';
35
+ import { appDirFor, appDirPayload, appImageHostRequirements, appImageRuntimeNotice, buildAppImage, findPinnedRuntime, stampAppDirTimes, } from '../utils/ship/appimage.js';
35
36
  import { buildDmgImage, dmgVolumeDir, dmgVolumeName } from '../utils/ship/dmg.js';
36
37
  import { buildFlatpakBundle } from '../utils/ship/flatpak.js';
37
38
  import { localizeMetadata } from '../utils/ship/localize-metadata.js';
38
- import { assertHostCanFinish, assertToolsInstalled, canCarryTicket, configuredFormats, defaultFormatIds, formatIdsFor, resolveFormats, windowsProgramDirName, FORMAT_IDS, FORMATS, } from '../utils/ship/formats.js';
39
+ import { assertHostCanFinish, assertKindCanPack, assertToolsInstalled, canCarryTicket, configuredFormats, defaultFormatIds, formatIdsFor, resolveFormats, windowsProgramDirName, FORMAT_IDS, FORMATS, } from '../utils/ship/formats.js';
39
40
  import { assertLayoutSupportsArch, hostLayout, layoutForOs, place, placeStage, resolveLayout, LAYOUT_NAMES, } from '../utils/ship/layout.js';
40
41
  import { isNodeRuntimeTarget, resolveNodeRuntime } from '../utils/ship/node-runtime.js';
41
42
  import { isUnder, SHARE } from '../utils/ship/share-dirs.js';
@@ -49,7 +50,7 @@ import { assertOverlayIsLicensed, planOverlay, planStage } from '../utils/ship/p
49
50
  import { assertHostCanSign, notarizeArtifact, stapleArtifact, resolveNotaryPlan, resolveSignPlan, signPayload, } from '../utils/ship/signing.js';
50
51
  import { renderLauncher } from '../utils/ship/launcher.js';
51
52
  import { buildRpm } from '../utils/ship/rpm.js';
52
- import { resolveShipApp, resolveShipBundle, resolveShipSettings, } from '../utils/ship/settings.js';
53
+ import { resolveShipApp, resolveShipBundle, resolveShipKind, resolveShipSettings, } from '../utils/ship/settings.js';
53
54
  import { assertExpectedTarget, assertFormatsStaged, formatTarget, overlayFiles, readStageManifest, resolveStageMtime, warnOnToolSkew, writeStageManifest, STAGE_MANIFEST_FILE, } from '../utils/ship/stage-manifest.js';
54
55
  import { directorySize, readStage, writePayload, writeStage } from '../utils/ship/stage-writer.js';
55
56
  const LOG = '[gjsify ship]';
@@ -276,6 +277,23 @@ async function assemble(args) {
276
277
  // afterwards costs the whole build for a refusal that was knowable up
277
278
  // front. Skipped under `--stage`, which is precisely the phase that does
278
279
  // NOT need the format's tooling — that asymmetry is the point of the split.
280
+ // THE THIRD REFUSAL THAT IS KNOWABLE UP FRONT, and it was the one paid for
281
+ // with a whole build: `appimage` needs a desktop entry at its AppDir root,
282
+ // `kind: 'cli'` stages none by design, and both facts are configuration. It
283
+ // used to surface inside the packer — after `runProjectBuild` — so a CLI
284
+ // project asking for an AppImage built everything first and was then told its
285
+ // payload could never have become one. The ICON half stays in the packer,
286
+ // because an icon is discovered and discovery legitimately reads build output.
287
+ //
288
+ // BEFORE `assertCanPack` AND NOT AFTER IT, which is an ordering between two
289
+ // refusals rather than a detail. `assertCanPack` says "not on THIS machine" and
290
+ // is answered by installing something; this one says "not for THIS PROJECT",
291
+ // which installing appimagetool would not fix. Reporting the machine first
292
+ // sends a CLI author to a GitHub release for a tool that was never going to
293
+ // help them — measured, because the e2e below asserted the message it wanted
294
+ // and only ever ran on a host that had the tool.
295
+ if (!args.stage)
296
+ assertKindCanPack(formats, resolveShipKind(ship, flatpak));
279
297
  if (!args.stage)
280
298
  for (const format of formats)
281
299
  assertCanPack(format);
@@ -949,6 +967,63 @@ async function packOne(input) {
949
967
  verbose: input.verbose,
950
968
  });
951
969
  break;
970
+ case 'appimage': {
971
+ // FROM THE PAYLOAD, like every other container here and NOT from the
972
+ // stage directory, so the three properties `writePayload` guarantees
973
+ // hold: the modes are the plan's, the stage's own sidecar stays out
974
+ // because it was never payload, and `--target appimage` alone works
975
+ // without another row having run first.
976
+ //
977
+ // The host requirement list is derived HERE rather than inside the
978
+ // packer, because it is the same pair of inputs `deriveDepends` takes
979
+ // one branch up — `input.namespaces` from the stage manifest and
980
+ // `facts.bundledTypelibs` from the payload. Two derivations would be
981
+ // two answers to "what does this artifact need from the machine", from
982
+ // one build, in two files.
983
+ const hostRequirements = appImageHostRequirements({
984
+ app: settings.app,
985
+ minGjsVersion: settings.minGjsVersion,
986
+ minNodeVersion: settings.minNodeVersion,
987
+ namespaces: input.namespaces,
988
+ bundledTypelibs: facts.bundledTypelibs,
989
+ });
990
+ const appDir = appDirFor(outRoot);
991
+ const tree = appDirPayload(settings, payload, hostRequirements);
992
+ // ONE `writePayload` FOR THE WHOLE AppDir, prefix and root files
993
+ // together, because that call WIPES: two of them would leave the
994
+ // previous run's `<appId>.desktop` and icon at a root the second call
995
+ // never cleaned, and appimagetool packs an AppDir with two desktop
996
+ // files without complaining about either.
997
+ writePayload(appDir, tree, '');
998
+ // AND THEN THE TIMES, which are the single difference between two packs
999
+ // of one build (measured, sha256): mksquashfs stores per-file mtimes
1000
+ // and `writePayload`'s own `mkdir`/`writeFileSync` leave the wall clock.
1001
+ stampAppDirTimes(appDir, tree, mtime);
1002
+ // PRINTED, not logged at `--verbose`. ADR 0024 § 9's objection to this
1003
+ // format is that "runs anywhere" is a claim the file cannot keep, and
1004
+ // the answer is that the file says what it does not carry — to the
1005
+ // person building it, every time, and not only in a document.
1006
+ console.log(`${LOG} the AppImage takes these from the host: ${hostRequirements.join(', ')}`);
1007
+ // AND WHAT IT EMBEDS, on the same terms and for the same reason. The
1008
+ // requirement list above says what the file does NOT carry; this says
1009
+ // where the one thing it DOES carry that this tree did not write came
1010
+ // from. With a pin that is a checkable claim (no network, and two packs
1011
+ // of one build embed identical bytes); without one appimagetool fetches
1012
+ // from a rolling tag, which still works and must still be said —
1013
+ // ADR 0024 § A26.1. Unconditional, never behind `--verbose`: the person
1014
+ // who can pin a runtime is the one reading a pack log.
1015
+ const runtimeFile = findPinnedRuntime(archLabel);
1016
+ console.log(`${LOG} ${appImageRuntimeNotice(archLabel, runtimeFile)}`);
1017
+ await buildAppImage({
1018
+ appDir,
1019
+ target,
1020
+ archLabel,
1021
+ runtimeFile,
1022
+ workDir: dirname(appDir),
1023
+ verbose: input.verbose,
1024
+ });
1025
+ break;
1026
+ }
952
1027
  case 'macos-app':
953
1028
  case 'windows-dir':
954
1029
  // ONE STATEMENT FOR TWO ROWS, folded because the code really is
@@ -0,0 +1,352 @@
1
+ import type { PayloadEntry } from './payload.js';
2
+ import type { PackSettings } from './types.js';
3
+ /** The tool this packer execs. One spelling, read by this module AND by the format row. */
4
+ export declare const APPIMAGE_TOOL = "appimagetool";
5
+ /**
6
+ * The environment variable the AppImage runtime reads to extract instead of mount.
7
+ *
8
+ * Named rather than inlined because two different programs read it for two
9
+ * different reasons — `appimagetool` when this packer runs it, and the artifact
10
+ * when a user runs that — and the spec asserts on the pair.
11
+ */
12
+ export declare const EXTRACT_AND_RUN = "APPIMAGE_EXTRACT_AND_RUN";
13
+ /**
14
+ * Where a PINNED AppImage runtime is looked for, and the variable that moves it.
15
+ *
16
+ * THE RUNTIME IS THE HALF OF THE ARTIFACT THIS TREE DOES NOT WRITE, and until it
17
+ * was pinned nothing pinned it: appimagetool fetches `runtime-<arch>` from
18
+ * `type2-runtime`'s ROLLING `continuous` tag on every pack (module header), so
19
+ * the ~940 KB of ELF a user downloads and executes arrived with no digest behind
20
+ * it, while `.docker/ci-fedora.Dockerfile` carefully pinned the tool that fetched
21
+ * it. Measured, and not a theoretical drift: `continuous`'s `runtime-x86_64` and
22
+ * the dated `20251108` release's differ in content at the same 944632 bytes.
23
+ *
24
+ * A DIRECTORY AND AN ENVIRONMENT VARIABLE, rather than a download this packer
25
+ * performs, because that is ADR 0024 § A25's rule applied one level down — a
26
+ * pack step that fetches is a release step that fails when GitHub does. The CI
27
+ * image puts a digest-checked file here; a workstation either does the same or
28
+ * takes the announced path below. Arch-named, `runtime-<arch>`, which is
29
+ * type2-runtime's own asset name, so pinning one is a copy and not a rename.
30
+ */
31
+ export declare const APPIMAGE_RUNTIME_DIR_ENV = "GJSIFY_APPIMAGE_RUNTIME_DIR";
32
+ /** The default home for {@link APPIMAGE_RUNTIME_DIR_ENV}, which the CI image fills. */
33
+ export declare const APPIMAGE_RUNTIME_DIR = "/usr/local/share/gjsify/appimage-runtime";
34
+ /**
35
+ * The AppDir's thumbnail, and the reason this packer writes it rather than
36
+ * letting appimagetool do it.
37
+ *
38
+ * MEASURED, AS A REPRODUCIBILITY DEFECT, and it is the kind only a byte
39
+ * comparison finds: appimagetool creates `.DirIcon` as a SYMLINK to the root icon
40
+ * when the AppDir does not already have one, and it does that AFTER
41
+ * {@link stampAppDirTimes} has run — so the link carries the wall clock, the
42
+ * AppDir root directory's own mtime moves with it, and mksquashfs stores both.
43
+ * Two `gjsify ship --target appimage` runs over ONE build then differ in sha256
44
+ * while every listing, mode, size and byte of content is identical (measured: 965
45
+ * differing bytes, the first inside `.digest_md5`, because the embedded digest
46
+ * follows the filesystem it covers). Four packs over the SAME AppDir are
47
+ * byte-identical, which is what makes this a mutation of the tree rather than a
48
+ * nondeterministic packer.
49
+ *
50
+ * A REGULAR FILE and not a symlink, for `dmg.ts`'s reason: `writePayload` writes
51
+ * regular files and nothing else — a property `tests/e2e/ship` asserts, and one
52
+ * `actions/upload-artifact` would silently dereference anyway. squashfs
53
+ * deduplicates the second copy, so it costs an inode and no data.
54
+ */
55
+ export declare const DIR_ICON_NAME = ".DirIcon";
56
+ /**
57
+ * The one directory the staged prefix goes under inside the AppDir.
58
+ *
59
+ * Exported because `stampAppDirTimes` and the e2e reader both address paths
60
+ * through it, and a second `'usr'` literal is the kind that stays right until
61
+ * somebody changes the first one.
62
+ */
63
+ export declare const APPDIR_PREFIX_DIR = "usr";
64
+ /**
65
+ * Where the AppDir is assembled, under the run's own output root.
66
+ *
67
+ * A directory of its own, never `out/`, for the reason `dmgVolumeDir` gives one
68
+ * format over: appimagetool packs everything it finds in the AppDir, so a stray
69
+ * sibling would ride into the image and the reader that would catch it is the
70
+ * same listing comparison that would then have to be relaxed to allow it.
71
+ */
72
+ export declare function appDirFor(outRoot: string): string;
73
+ /**
74
+ * What the AppImage does NOT carry, derived from the payload rather than authored.
75
+ *
76
+ * THE HONEST HALF OF ADR 0024 § 9, as data. The same scan that gives the `.deb`
77
+ * its `Depends: gir1.2-gtk-4.0` gives this its `Gtk-4.0`, so the two artifacts
78
+ * built from one payload cannot disagree about what the host has to provide —
79
+ * and the AppImage's version is distro-NEUTRAL on purpose, because there is no
80
+ * distribution to name package names in. A user reading `Gtk-4.0` can find it on
81
+ * any system; a user reading `gir1.2-gtk-4.0` on Fedora cannot.
82
+ *
83
+ * The interpreter is first and always present: it is the requirement that is
84
+ * never satisfied by accident, and the one {@link renderAppRun} can check from a
85
+ * shell script.
86
+ */
87
+ export declare function appImageHostRequirements(input: {
88
+ app: PackSettings['app'];
89
+ minGjsVersion?: string;
90
+ minNodeVersion?: string;
91
+ namespaces: readonly string[];
92
+ bundledTypelibs?: readonly string[];
93
+ }): string[];
94
+ /**
95
+ * The version this payload's interpreter must be at least, as the project declared it.
96
+ *
97
+ * ONE DECISION, TWO READERS, which is why it is a function and not two ternaries:
98
+ * {@link appImageHostRequirements} PRINTS this floor and {@link renderAppRun}
99
+ * CHECKS it, and an artifact whose message names 1.86 while its script compares
100
+ * against something else is worse than one that does neither.
101
+ */
102
+ export declare function interpreterFloor(input: {
103
+ app: PackSettings['app'];
104
+ minGjsVersion?: string;
105
+ minNodeVersion?: string;
106
+ }): string;
107
+ /**
108
+ * The `AppRun` the AppImage runtime execs, and the one check it makes first.
109
+ *
110
+ * IT EXECS THE STAGED LAUNCHER AND ADDS NOTHING TO IT. `bin/<name>` already
111
+ * resolves its own prefix — `readlink -f "$0"` then two `dirname`s
112
+ * (`renderPrefixLauncher`) — and exports `XDG_DATA_DIRS`, `GI_TYPELIB_PATH`,
113
+ * `GJSIFY_LOCALE_DIR` and `GJSIFY_FONT_DIR` relative to it. Inside a mounted
114
+ * image that resolves to `/tmp/.mount_xxxx/usr`, measured, so every locator the
115
+ * `.deb` sets up is already correct here. Re-exporting any of them from AppRun
116
+ * would be a second answer to a question the payload answers, and the copy that
117
+ * drifts is the one nothing tests: `tests/e2e/ship-layout` compares the staged
118
+ * trees, not this script.
119
+ *
120
+ * WHAT IT DOES ADD is the refusal ADR 0024 § 9 asks for. An AppImage whose
121
+ * interpreter is missing exits with the loader's own message — `gjs: not found`
122
+ * from a shell, or nothing at all when a desktop launches it — and the user
123
+ * concludes the download is broken. `command -v` costs one fork and turns that
124
+ * into a sentence naming the runtime, this file's promise and the escape hatch.
125
+ * The typelib half is deliberately NOT checked here: girepository's search path
126
+ * is not a shell-visible thing, and GJS's own "Typelib file for namespace 'Gtk'
127
+ * not found" is already precise. Listing them in the refusal is what this file
128
+ * can honestly do — checking them would be a probe that guesses.
129
+ *
130
+ * AND THE FLOOR IS CHECKED, FAIL-OPEN, which is the one design decision in this
131
+ * script. `command -v gjs` alone accepted GJS 1.70 while the message beside it
132
+ * said `gjs (>= 1.86)` — a floor the `.deb` enforces through `Depends:` and this
133
+ * artifact merely printed, so the failure it exists to prevent came back one
134
+ * import later. The check costs the same fork `command -v` already cost.
135
+ *
136
+ * FAIL-OPEN IS THE POINT AND NOT A HEDGE. A version comparison in `/bin/sh` that
137
+ * gets it wrong REFUSES A WORKING SYSTEM, which is strictly worse than not
138
+ * checking: the user cannot argue with an artifact. So the refusal fires only on
139
+ * two integers that were actually parsed out of the interpreter's own
140
+ * `--version`, and every other outcome — no output, a spelling this `sed` does
141
+ * not match, a distro build that prints something else entirely — RUNS THE
142
+ * APPLICATION. `gjs --version` prints `gjs 1.88.1` and `node --version` prints
143
+ * `v24.19.0`; both reduce to a major and a minor, and a floor with no minor
144
+ * (`24`) compares as `24.0`.
145
+ *
146
+ * EXIT 126 AND NOT 127 for the too-old case, because the shell's own vocabulary
147
+ * already separates them: 127 is "not found", 126 is "found and cannot be run".
148
+ * A wrapper script that wants to tell the two apart can, and the message says
149
+ * which it is either way.
150
+ */
151
+ export declare function renderAppRun(settings: PackSettings, hostRequirements: readonly string[]): string;
152
+ /**
153
+ * The icon appimagetool needs at the AppDir root, chosen from the payload.
154
+ *
155
+ * AN APPIMAGE NEEDS TWO FILES THE PREFIX ALREADY HAS, AT A PLACE IT DOES NOT:
156
+ * appimagetool refuses an AppDir without a `.desktop` at its root, and the file
157
+ * named by that entry's `Icon=` must sit beside it. `plan.ts` stages both — the
158
+ * entry at `share/applications/<appId>.desktop` and every icon renamed to
159
+ * `<appId>` under `share/icons/hicolor/…` — so this function is a SELECTION over
160
+ * the payload rather than anything new in the stage, which is ADR 0024 § 2's
161
+ * "one payload, a handful of layouts" holding for a fourth format.
162
+ *
163
+ * LARGEST RASTER WINS, and the size comes from the hicolor directory rather than
164
+ * from reading the file: `share/icons/hicolor/256x256/apps/<id>.png` says 256 in
165
+ * its path, and a PNG header read would be a decoder this packer would then own.
166
+ * `scalable` sorts above every raster size as the SVG fallback and `symbolic` is
167
+ * excluded outright — its staged name is `<appId>-symbolic`, which is not what
168
+ * the desktop entry's `Icon=` says, so shipping it as the root icon installs an
169
+ * icon nothing ever looks up (`plan.ts` documents the same rule for the theme).
170
+ */
171
+ /**
172
+ * The pinned runtime for this architecture, or `undefined` when none is staged here.
173
+ *
174
+ * PURE APART FROM ONE INJECTED PROBE, so both answers are testable on a host that
175
+ * has neither — the split {@link appImageToolArgs} draws for the flags. `exists`
176
+ * is a parameter for exactly that reason and defaults to the real one.
177
+ */
178
+ export declare function findPinnedRuntime(archLabel: string, env?: NodeJS.ProcessEnv, exists?: (path: string) => boolean): string | undefined;
179
+ /**
180
+ * What this pack is about to do about the runtime, as ONE sentence `ship` prints
181
+ * unconditionally.
182
+ *
183
+ * DECLARE RATHER THAN IMPLY — {@link appImageHostRequirements}'s rule, applied to
184
+ * the other half of the artifact. With a pin the claim is checkable: no network,
185
+ * and two packs of one build agree because the embedded bytes are fixed. Without
186
+ * one the pack still works and still produces a correct-architecture container —
187
+ * so refusing would cost the three architectures nothing here pins, for a
188
+ * property they never had. What it must not do is happen silently: an AppImage
189
+ * built this way carries bytes from a rolling tag that nothing in this tree can
190
+ * name, and the person who can fix that is the one reading this line.
191
+ */
192
+ export declare function appImageRuntimeNotice(archLabel: string, runtimeFile: string | undefined): string;
193
+ export declare function selectAppDirIcon(payload: readonly PayloadEntry[], appId: string): PayloadEntry | undefined;
194
+ /**
195
+ * Refuse a payload that cannot become an AppImage, naming the missing half.
196
+ *
197
+ * BEFORE appimagetool RATHER THAN THROUGH IT, and the two refusals it replaces
198
+ * are why: a `kind: 'cli'` project stages no desktop entry at all, and
199
+ * appimagetool answers that with `Desktop file not found, aborting` — true, and
200
+ * about a file the author never wrote and cannot find. Same for the icon. Both
201
+ * failures are decided by the project's OWN configuration (`gjsify.ship.kind`,
202
+ * `gjsify.ship.icon`), so the message that helps is the one that names the key.
203
+ *
204
+ * Separate from `assertToolsInstalled` and `assertHostCanFinish` for the reason
205
+ * those two are separate from each other (ADR 0024 § A3): three failures, three
206
+ * different fixes — a different machine, a package, or a line in package.json.
207
+ */
208
+ export declare function assertAppImageIsPackable(payload: readonly PayloadEntry[], settings: PackSettings): void;
209
+ /**
210
+ * The whole AppDir as one payload: the prefix under `usr/`, plus the three files
211
+ * at its root.
212
+ *
213
+ * PURE, AND ONE LIST RATHER THAN A WRITER, which is the shape `msi.ts` and
214
+ * `dmg.ts` already have — `packOne` owns the single `writePayload` call for every
215
+ * format, and the packer module owns what goes in it. Two calls here would be two
216
+ * wipes, and the second would not clean the first: an AppDir root still holding
217
+ * the PREVIOUS app id's `.desktop` and icon is an AppDir appimagetool packs
218
+ * without complaint, because it looks for *a* desktop file and finds two.
219
+ *
220
+ * `usr/` AND NOT THE APPDIR ROOT — that prefix is the whole layout difference
221
+ * between this format and the `.deb` beside it, and it is why
222
+ * `FormatDescriptor.prefix` can stay `/usr`. The staged launcher walks up two
223
+ * directories from its own resolved path, so under a mount it computes
224
+ * `<mount>/usr` and every locator it exports is already right. A payload written
225
+ * at the root would make it compute the MOUNTPOINT, and the app would look for
226
+ * its schemas one directory too high — at exit 0, until the first
227
+ * `Gio.Settings.new()`.
228
+ */
229
+ export declare function appDirPayload(settings: PackSettings, payload: readonly PayloadEntry[], hostRequirements: readonly string[]): PayloadEntry[];
230
+ /**
231
+ * The argument vector, as data.
232
+ *
233
+ * Pure, so every flag is unit-testable on a host with no `appimagetool` — the
234
+ * same split `hdiutilCreateArgs` draws for `hdiutil` and `renderShipFlatpakManifest`
235
+ * for `flatpak-builder`: what the tool is TOLD is checkable everywhere, what the
236
+ * tool DOES needs the tool.
237
+ *
238
+ * `--no-appstream` IS A DECISION AND NOT A DEFAULT. appimagetool otherwise runs
239
+ * `appstreamcli validate-tree` over the AppDir, which would make the pack succeed
240
+ * or fail depending on whether a package unrelated to packaging is installed —
241
+ * green on a workstation with `appstream` and red in a container without it, over
242
+ * a payload that is byte-identical. A validator whose presence changes the
243
+ * outcome is the class this repository calls green-CI-that-checked-nothing, read
244
+ * backwards. The MetaInfo is still validated, by the tool that exists for it:
245
+ * `gjsify flatpak check --appstream` runs `appstreamcli validate --strict` on
246
+ * demand, where a missing `appstreamcli` is the point of the command rather than
247
+ * a surprise inside another one.
248
+ *
249
+ * `--comp zstd` is pinned for `hdiutilCreateArgs`' reason one format over: it is
250
+ * 1.9.1's current default, and a default is a thing that changes. The reader the
251
+ * oracle leg runs is `unsquashfs` from squashfs-tools, which needs its zstd
252
+ * support compiled in — measured present on Fedora 44 (4.6.1) and on
253
+ * ubuntu-24.04's 4.6.1. Pinning means the day appimagetool switches to something
254
+ * newer, this file changes and the reader is considered, instead of the reader
255
+ * silently losing the ability to open what we ship.
256
+ *
257
+ * `--runtime-file` IS PASSED WHEN THERE IS ONE TO PASS, and its absence is the
258
+ * only thing in this vector that is not a decision — see
259
+ * {@link findPinnedRuntime}. With it, the pack embeds bytes this tree pinned and
260
+ * needs no network (measured: the whole pack succeeds with the network blocked,
261
+ * and two packs are byte-identical). Without it appimagetool fetches its own, the
262
+ * pack is announced as doing so, and the artifact is still correct — just built
263
+ * from something nothing here can name.
264
+ */
265
+ export declare function appImageToolArgs(input: {
266
+ appDir: string;
267
+ target: string;
268
+ runtimeFile?: string;
269
+ }): string[];
270
+ /**
271
+ * The environment appimagetool is run with — both entries REQUIRED, neither a hint.
272
+ *
273
+ * `ARCH` because appimagetool derives the architecture from the ELF binaries it
274
+ * finds in the AppDir, and a `--app gjs` payload has none: it is JavaScript and a
275
+ * `/bin/sh` launcher. Without this the tool exits 1 with "Could not determine
276
+ * architecture automatically", on a payload that is perfectly fine. The value is
277
+ * the format row's `archName`, so the architecture inside the file and the one in
278
+ * its name are one decision.
279
+ *
280
+ * `APPIMAGE_EXTRACT_AND_RUN` because appimagetool is itself an AppImage and
281
+ * mounts itself through libfuse to start — see the module header. Set
282
+ * unconditionally: a native `appimagetool` build ignores it, so there is no host
283
+ * for which this is wrong and no flag for a CI author to discover.
284
+ */
285
+ export declare function appImageToolEnv(archLabel: string): Record<string, string>;
286
+ /**
287
+ * What a non-zero `appimagetool` exit is, in the order a host actually hits them.
288
+ *
289
+ * PURE, so the one message a user reads at the worst moment is assertable without
290
+ * a container — the same split {@link appImageToolArgs} draws. It was inline until
291
+ * the list was found to be missing its FIRST entry, which is the shape a message
292
+ * that nothing reads back tends to have.
293
+ *
294
+ * THE FIRST CAUSE DEPENDS ON WHETHER A RUNTIME WAS PINNED, and getting that
295
+ * wrong is what this function existed to fix in the first place: with no pin the
296
+ * download is where an offline host fails (measured — exit 1, no file, `Failed to
297
+ * download runtime file`), and with one there is no download to fail, so naming
298
+ * it would send a reader with a working network to debug their firewall. So the
299
+ * pinned branch names the pinned FILE instead, which is the thing that is new in
300
+ * that configuration and the only one this tree chose.
301
+ */
302
+ export declare function appImageToolFailureMessage(exit: string, runtimeFile?: string): string;
303
+ export interface AppImagePackInput {
304
+ appDir: string;
305
+ target: string;
306
+ archLabel: string;
307
+ verbose: boolean;
308
+ /** The pinned runtime to embed, or `undefined` to let appimagetool fetch one. */
309
+ runtimeFile?: string;
310
+ /** Working root, so the log can name the directory that became the image. */
311
+ workDir: string;
312
+ }
313
+ /**
314
+ * Run appimagetool over the AppDir.
315
+ *
316
+ * THE FAILURE PATHS ARE THE POINT. A packer that execs a foreign tool inherits
317
+ * that tool's silence, and appimagetool's container failures were MEASURED on
318
+ * `fedora:44` rather than guessed. Without `APPIMAGE_EXTRACT_AND_RUN=1` it exits
319
+ * **127** pointing at the AppImageKit FUSE wiki — which is why
320
+ * {@link appImageToolEnv} sets that variable and this branch should never see it.
321
+ * Without `file(1)` it exits **1** with "file command is missing but required",
322
+ * EVEN with `ARCH` set, which is the failure a minimal image really hits and
323
+ * which says nothing about packaging. And without a network it exits **1** having
324
+ * written nothing, because the runtime is fetched rather than embedded — see the
325
+ * module header. {@link appImageToolFailureMessage} names all four.
326
+ *
327
+ * AND THE ARTIFACT IS VERIFIED TO EXIST. appimagetool prints "Success" and a
328
+ * request to submit to AppImageHub; it does not guarantee the destination was
329
+ * written, and a packer whose contract is "there is a file at `target`" must not
330
+ * hand `statSync` a path that is not there and report the ENOENT as a `ship` bug.
331
+ */
332
+ export declare function buildAppImage(input: AppImagePackInput): Promise<void>;
333
+ /**
334
+ * Every path an AppDir holding this payload has, files and the directories above
335
+ * them, deepest LAST.
336
+ *
337
+ * Pure and separate from the stamping, so the "which paths" half is testable with
338
+ * no filesystem at all — and so the answer comes from the payload rather than
339
+ * from a directory walk, which would read back whatever the writer happened to
340
+ * leave rather than what it was told to write.
341
+ */
342
+ export declare function appDirPaths(payload: readonly PayloadEntry[]): string[];
343
+ /**
344
+ * Give every path in the AppDir one mtime.
345
+ *
346
+ * See the module header: this is the single difference between two packs of one
347
+ * build, measured by sha256. `utimesSync` on a directory is legal and is where a
348
+ * squashfs directory inode's time comes from, so directories are stamped as well
349
+ * — `writePayload`'s `mkdir` gives them the wall clock and nothing else would
350
+ * take it away.
351
+ */
352
+ export declare function stampAppDirTimes(appDir: string, payload: readonly PayloadEntry[], mtime: number): void;