Build: package scripts that swallow their exit status

[JumpLink]

The mechanism

A package script whose entire body is a single gjsify … command exits 0 no matter what that command did.

Measured on the pinned CLI 0.16.3 — runScript in @gjsify/cli/dist/cli.gjs.mjs:

let Y = isGjs() ? gjsifyInProcessArgv(I, a) : null;
if (Y) {
  try { const { runCli } = await import(...); await runCli(Y); }
  catch (e) { logger.error(e.message); process.exit(1); }
  process.exit(process.exitCode == null ? 0 : Number(process.exitCode));
}

gjsifyInProcessArgv returns non-null only when the body tokenizes as one plain gjsify … command (tokenizeSimpleCommand bails on any of |&;<>`$()\ * ? { } [ ] ~ # !). On that path the sub-command runs in-process and the wrapper exits with process.exitCode ?? 0 — and gjsify build and gjsify run report failure without setting process.exitCode. Anything with a shell operator takes the spawn path and the status survives. gjsify tsc is unaffected because it spawns gjs.

Reproduction:

"p1": "gjsify run /tmp/throws.gen.js"                  -> gjsify workspace <pkg> p1  == exit 0
"p2": "gjsify run /tmp/throws.gen.js && echo SECOND"   -> exit 1, SECOND not printed
"p3": "gjs -m /tmp/throws.gen.js"                      -> exit 1
"p4": "exit 7"                                         -> exit 1

What is still affected

#178 chained the leaves in learn, translations and examples, which is where it was actively hiding failures (the tutorial artifact check and the catalog check both exited 0 while reporting problems). These remain:

• packages/app-gnome: build:gjs, build:resources, build:schema — so gjsify workspace @learn6502/app-gnome build reports success when the bundle, the gresource or the GSettings schema failed to build. This one ships.
• packages/app-web: build:app (and therefore build).
• packages/cli: build.
• root: build (gjsify foreach --topological-dev build), check (gjsify foreach -t check), setup, start:*, format, lint — worth measuring whether foreach propagates before changing anything.

check scripts that are gjsify tsc … (core, common-ui, app-web, app-android, app-gnome's check:typescript) were measured and do propagate — verified by introducing a type error and getting exit 1.

Fix

Upstream, in gjsify: the in-process path should take the sub-command's status rather than reading a process.exitCode its commands never set. Until that lands, AGENTS.md (§ Package scripts) records the rule so the chains are not "simplified" back into single-command steps.

[JumpLink]

Counter-measurement, because this should not stand unqualified.

On the CLI installed in this checkout, @gjsify/cli 0.16.3, the swallowing does not reproduce. Three script shapes, each with a body that fails:

script body	exit
gjsify run dist/check.gen.js (a file)	1
gjsify run probe:leaf (a script name, single plain command)	1
gjsify run probe:leaf && true (chained)	1
gjsify build /nonexistent-file.js --app gjs --outfile dist/x.js	1

The last one is the exact shape described above: a script body that is a single plain gjsify build which fails. It propagates.

I also checked the merged catalog gate on a clean worktree of main, with one <tt> literal deliberately mangled in ta.po: gjsify workspace @learn6502/translations check exits 1 and prints 1 string(s) failed structural validation. That gate is not blind.

What probably explains the disagreement is a version skew, and that is the finding worth keeping. .github/workflows/ci.yml installs @gjsify/cli@^0.8.0 in both jobs. This checkout runs 0.16.3, and the published version is 0.46.0. So CI validates every push with a CLI far behind both the local development environment and the current release, and behaviour measured in one place says little about the other.

That makes two separate things to decide:

1. Whether the in-process dispatch swallows a status on 0.8.x, which is what CI actually runs. Untested by me. If it does, this issue is real for the only environment that gates main, and the version skew is how it stayed invisible.
2. The skew itself. ^0.8.0 pins CI to a line nobody develops against. Worth its own change regardless of how (1) resolves.

Independently of both, collapsing the :gen/:run script pairs into && chains (PR #178) is right: it takes the spawn path, so the status survives whichever dispatch the installed CLI chooses. That is worth keeping as a property of the scripts rather than a bet on a CLI version.