@gjsify/cli 0.54.0 → 0.55.0

package/lib/commands/blueprint/types.js

@@ -13,8 +13,9 @@
 // `scripts/` of ours, so without this flag it could generate sidecars and never hold them.
 // The two share the derivation; what is duplicated is the byte comparison.
 import { readdirSync, readFileSync, statSync, writeFileSync } from 'node:fs';
-import { basename, isAbsolute, join, resolve } from 'node:path';
+import { basename, dirname, isAbsolute, join, resolve } from 'node:path';
 import { emitTypedSidecar, parseBlueprint, sidecarPathFor } from '@gjsify/blueprint';
+import { emitFormatForTree } from '@gjsify/blueprint/oxfmt';
 /** What a walk never descends into: build output, and other projects' sources. */
 const SKIP = new Set(['node_modules', 'dist', 'lib', '.git']);
 /**
@@ -44,6 +45,29 @@ function blueprintsUnder(path, found) {
     }
     return found;
 }
+/**
+ * The emitter options for the tree a `.blp` lives in, memoized per directory.
+ *
+ * ONE directory of the walk is a sidecar's, not the CWD's, and that is the difference between
+ * right and right-by-luck in a monorepo: a package with its own `.oxfmtrc` gets that package's
+ * width, and running the command from the repo root still writes that package's indent. The walk
+ * itself is `emitFormatForTree`'s — the same one the drift gate and the bundler plugin use, so
+ * three callers cannot answer "which config does the formatter read" three ways (ADR 0088 §
+ * Consequences: the emitter once read `printWidth` and hardcoded a 4-space indent beside it, which
+ * is a `tabWidth: 2` consumer's red `oxfmt --check`).
+ *
+ * Memoized because the walk touches the filesystem once per `.blp` and a tree of a thousand
+ * `.blp` files would do that a thousand times; one read per distinct directory, not per file.
+ */
+const formatCache = new Map();
+const formatFor = (dir) => {
+    const cached = formatCache.get(dir);
+    if (cached !== undefined)
+        return cached;
+    const format = emitFormatForTree(dir);
+    formatCache.set(dir, format);
+    return format;
+};
 export const blueprintTypesCommand = {
     command: 'types [paths..]',
     description: 'Generate the `<name>.d.blp.ts` type sidecar for each .blp (ADR 0088), so `import { build }` / ' +
@@ -84,7 +108,7 @@ export const blueprintTypesCommand = {
             // init, and the path here is the user's, on their machine. `@gjsify/blueprint` cannot
             // take the name itself — see `typed-exports.mjs` § `emitTypedSidecar`.
             const ast = parseBlueprint(readFileSync(file, 'utf8'), file);
-            const expected = emitTypedSidecar(ast, basename(file));
+            const expected = emitTypedSidecar(ast, basename(file), formatFor(dirname(file)));
             let current;
             try {
                 current = readFileSync(sidecar, 'utf8');

package/lib/commands/ship.js

@@ -34,6 +34,7 @@ import { isGtkRuntimeTarget, stageAppRuntime } from '../utils/ship/app-runtime.j
 import { discoverPayload } from '../utils/ship/discover.js';
 import { appDirFor, appDirPayload, appImageHostRequirements, appImageRuntimeNotice, buildAppImage, findPinnedRuntime, stampAppDirTimes, } from '../utils/ship/appimage.js';
 import { buildDmgImage, dmgVolumeDir, dmgVolumeName } from '../utils/ship/dmg.js';
+import { assertNoDroppedFlatpakModules } from '../utils/ship/flatpak-config.js';
 import { buildFlatpakBundle } from '../utils/ship/flatpak.js';
 import { iconSizes, resolveAppIcon } from '../utils/ship/icons.js';
 import { localizeMetadata } from '../utils/ship/localize-metadata.js';
@@ -252,6 +253,10 @@ async function assemble(args) {
                 'thing as an error.');
         }
     }
+    // Under `--stage` too: the stage records the Flatpak settings, and a stage
+    // that quietly omits the project's modules packs without them later.
+    if (formats.some((format) => format.id === 'flatpak'))
+        assertNoDroppedFlatpakModules(flatpak);
     if (!args.stage)
         assertPackable(formats, layout, args.os === undefined ? 'host' : 'positional', unusable);
     // BEFORE the build, beside `assertCanPack` and for the same reason: a

package/lib/types/config-data.d.ts

@@ -706,6 +706,11 @@ export interface ShipSignOptions {
  * the one thing ADR 0024 § 8 gates the whole migration on. A project that has
  * to BUILD something inside the sandbox still has `gjsify flatpak init` +
  * `gjsify flatpak build`, unchanged.
+ *
+ * Setting `gjsify.flatpak.modules` / `extraModules` and shipping the `flatpak`
+ * target is REFUSED (`assertNoDroppedFlatpakModules`) rather than ignored:
+ * those keys are read by `flatpak init` only, and dropping them at exit 0 hid an
+ * `extra-data` module until the app ran without its downloaded binary.
  */
 export interface ShipFlatpakOptions {
     /**

package/lib/utils/ship/flatpak-config.d.ts

@@ -64,3 +64,19 @@ export interface ResolvedShipFlatpak {
  * has somewhere else to point at.
  */
 export declare function resolveShipFlatpakSettings(input: ShipFlatpakInput): ResolvedShipFlatpak;
+/**
+ * Refuse a Flatpak ship that would silently drop the project's own modules.
+ *
+ * `gjsify.flatpak.modules` / `extraModules` are read by `gjsify flatpak init`
+ * only; `ship` renders exactly one module, the staged payload (ADR 0024 § 2),
+ * and the keys' absence from {@link ShipFlatpakOptions} is deliberate. The
+ * defect was the silence: a project that moved to `ship` kept the keys, got a
+ * manifest without its `extra-data` module and exit 0, and found out when the
+ * app started without the binary the module downloads. A key `ship` does not
+ * read must not be one it ignores quietly, so the run stops BEFORE the build.
+ *
+ * Called only when `flatpak` is among the formats being made: the same keys
+ * still drive `gjsify flatpak init`, and a `ship --target deb` has nothing to
+ * drop them from.
+ */
+export declare function assertNoDroppedFlatpakModules(flatpak: ConfigDataFlatpak): void;

package/lib/utils/ship/flatpak-config.js

@@ -120,6 +120,32 @@ export function resolveShipFlatpakSettings(input) {
     };
     return { settings, warnings: fromLegacy.length === 0 ? [] : [deprecationWarning(fromLegacy)] };
 }
+/**
+ * Refuse a Flatpak ship that would silently drop the project's own modules.
+ *
+ * `gjsify.flatpak.modules` / `extraModules` are read by `gjsify flatpak init`
+ * only; `ship` renders exactly one module, the staged payload (ADR 0024 § 2),
+ * and the keys' absence from {@link ShipFlatpakOptions} is deliberate. The
+ * defect was the silence: a project that moved to `ship` kept the keys, got a
+ * manifest without its `extra-data` module and exit 0, and found out when the
+ * app started without the binary the module downloads. A key `ship` does not
+ * read must not be one it ignores quietly, so the run stops BEFORE the build.
+ *
+ * Called only when `flatpak` is among the formats being made: the same keys
+ * still drive `gjsify flatpak init`, and a `ship --target deb` has nothing to
+ * drop them from.
+ */
+export function assertNoDroppedFlatpakModules(flatpak) {
+    const dropped = ['modules', 'extraModules'].filter((key) => (flatpak[key]?.length ?? 0) > 0);
+    if (dropped.length === 0)
+        return;
+    const list = dropped.map((key) => `gjsify.flatpak.${key}`).join(' and ');
+    throw new Error(`gjsify ship: ${list} ${dropped.length > 1 ? 'are' : 'is'} set, but the \`flatpak\` target renders ` +
+        'ONE module, the staged payload, and would drop ' +
+        `${dropped.length > 1 ? 'them' : 'it'} (ADR 0024 § 2). Build this Flatpak with ` +
+        '`gjsify flatpak init` + `gjsify flatpak build`, which honour the key, or leave `flatpak` out of ' +
+        '`--target` / `gjsify.ship.targets`.');
+}
 /** One line, naming every key still read from the old block and where each goes. */
 function deprecationWarning(keys) {
     const list = keys.map((key) => `gjsify.flatpak.${key}`).join(', ');

package/lib/utils/ship/formats.js

@@ -132,12 +132,14 @@ function macosArch(arch, _archIndependent) {
 /**
  * `process.arch` → the name Windows and everything that targets it use.
  *
- * ONE ROW, and it is not caution: `wingtk/gvsbuild` hardcodes
- * `self.platform = "x64"` and publishes no arm64 GTK, so there is nothing to build
- * `@gjsify/gtk-runtime-win32-arm64` out of and no GTK 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.
+ * 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.
  *
  * `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
@@ -734,7 +736,8 @@ export const FORMATS = {
     //   * there is no `Info.plist` and no metadata file at all: what a Windows
     //     installer says about an application lives in the `.msi`'s own tables
     //     (#1354 M5), which is why `Layout.metadata` answers `[]` here.
-    //   * `x64` alone, and the blocker is upstream — see `WINDOWS_ARCH`.
+    //   * `x64` alone, and the blocker is a package of ours we have not built —
+    //     see `WINDOWS_ARCH`.
     //
     // NEITHER IS SIGNED BY DEFAULT, and Windows is the softer of the two asymmetries
     // ADR 0024 § A5 records: Gatekeeper BLOCKS an unsigned `.app`, while SmartScreen

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

@@ -230,9 +230,10 @@ export interface Layout {
      *
      *  * a REASON. `archName` answers "no Windows architecture is known for
      *    `process.arch` \"arm64\"", which reads as a gap in our table. The truth is
-     *    that gvsbuild publishes no arm64 GTK, the blocker is upstream, and #1117
-     *    is where it is tracked — and the difference between "unsupported" and
-     *    "here is what would have to change" is the whole value of the message.
+     *    a package this project has not built yet — ordered in
+     *    `status/open-todos/windows.md` and tracked in #1117 — and the difference
+     *    between "unsupported" and "here is what would have to change" is the whole
+     *    value of the message.
      *  * a STAGE-TIME warning at the flag that caused it (`commands/ship.ts`), for
      *    a phase that deliberately does not refuse — `tests/e2e/ship-layout`
      *    assembles all three layouts from ONE payload on purpose, and that
@@ -314,9 +315,9 @@ export declare function hostLayout(platform?: string): Layout;
  * AT STAGE TIME, which is the whole point — see {@link Layout.arches}. The
  * message carries the row's own `why` rather than a generic "unsupported", because
  * the two refusals a reader can act on are different jobs: `x64` is what a Windows
- * artifact is built for TODAY, and `win32-arm64` is blocked in a repository we do
- * not own. Telling an author "unknown architecture" for the second one would send
- * them to look for a flag.
+ * artifact is built for TODAY, and `win32-arm64` waits on a package of ours that
+ * does not exist yet. Telling an author "unknown architecture" for the second one
+ * would send them to look for a flag.
  *
  * `process.arch` spelling on both sides, so the value quoted back is the one the
  * user typed after `--arch`.

package/lib/utils/ship/layout.js

@@ -378,19 +378,22 @@ export const LAYOUTS = {
                 ]
                 : [];
         },
-        // ONE, and the blocker is a project we do not own. `wingtk/gvsbuild`
-        // hardcodes `self.platform = "x64"` in `utils/base_project.py` and its last
-        // five releases publish exactly two assets each, both x64 — so there is no
-        // arm64 GTK to build `@gjsify/gtk-runtime-win32-arm64` OUT OF, and on
-        // Windows that bundle is the only GTK there is. `@gjsify/node-gi` declares
-        // `win32-x64` only for the same reason. Tracked in #1117, which also
-        // records why an exploratory arm64 leg must NOT be added: its first step
-        // downloads a ZIP that does not exist, so it would be red by construction.
+        // 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.
         arches: {
             only: ['x64'],
-            why: 'gvsbuild publishes no arm64 GTK (it hardcodes `self.platform = "x64"`), so there is nothing ' +
-                'to build `@gjsify/gtk-runtime-win32-arm64` out of and no GTK for a Windows/ARM artifact to ' +
-                'load — the blocker is upstream and is tracked in gjsify/gjsify#1117',
+            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',
         },
     },
 };
@@ -502,9 +505,9 @@ export function hostLayout(platform = process.platform) {
  * AT STAGE TIME, which is the whole point — see {@link Layout.arches}. The
  * message carries the row's own `why` rather than a generic "unsupported", because
  * the two refusals a reader can act on are different jobs: `x64` is what a Windows
- * artifact is built for TODAY, and `win32-arm64` is blocked in a repository we do
- * not own. Telling an author "unknown architecture" for the second one would send
- * them to look for a flag.
+ * artifact is built for TODAY, and `win32-arm64` waits on a package of ours that
+ * does not exist yet. Telling an author "unknown architecture" for the second one
+ * would send them to look for a flag.
  *
  * `process.arch` spelling on both sides, so the value quoted back is the one the
  * user typed after `--arch`.

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

@@ -423,6 +423,8 @@ export interface PackSettings {
  * model back in the tree — which is the one thing § 8 gates the whole migration
  * on. A project that genuinely needs to BUILD something inside the sandbox
  * still has `gjsify flatpak init` + `gjsify flatpak build`, unchanged.
+ * A project that sets those keys and ships `flatpak` anyway is refused up front
+ * (`assertNoDroppedFlatpakModules`), never silently stripped of them.
  */
 export interface ShipFlatpakSettings {
     /** Runtime id, e.g. `org.gnome.Platform`. */

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@gjsify/cli",
-    "version": "0.54.0",
+    "version": "0.55.0",
     "description": "CLI for Gjsify",
     "type": "module",
     "main": "lib/index.js",
@@ -142,22 +142,22 @@
         "cli"
     ],
     "dependencies": {
-        "@gjsify/blueprint": "^0.54.0",
-        "@gjsify/buffer": "^0.54.0",
-        "@gjsify/create-app": "^0.54.0",
-        "@gjsify/node-globals": "^0.54.0",
-        "@gjsify/node-polyfills": "^0.54.0",
-        "@gjsify/npm-registry": "^0.54.0",
-        "@gjsify/resolve-npm": "^0.54.0",
-        "@gjsify/rolldown-plugin-gjsify": "^0.54.0",
-        "@gjsify/vite-plugin-blueprint": "^0.54.0",
-        "@gjsify/rolldown-plugin-pnp": "^0.54.0",
-        "@gjsify/semver": "^0.54.0",
-        "@gjsify/tar": "^0.54.0",
-        "@gjsify/tsc": "^0.54.0",
-        "@gjsify/utils": "^0.54.0",
-        "@gjsify/web-polyfills": "^0.54.0",
-        "@gjsify/workspace": "^0.54.0",
+        "@gjsify/blueprint": "^0.55.0",
+        "@gjsify/buffer": "^0.55.0",
+        "@gjsify/create-app": "^0.55.0",
+        "@gjsify/node-globals": "^0.55.0",
+        "@gjsify/node-polyfills": "^0.55.0",
+        "@gjsify/npm-registry": "^0.55.0",
+        "@gjsify/resolve-npm": "^0.55.0",
+        "@gjsify/rolldown-plugin-gjsify": "^0.55.0",
+        "@gjsify/vite-plugin-blueprint": "^0.55.0",
+        "@gjsify/rolldown-plugin-pnp": "^0.55.0",
+        "@gjsify/semver": "^0.55.0",
+        "@gjsify/tar": "^0.55.0",
+        "@gjsify/tsc": "^0.55.0",
+        "@gjsify/utils": "^0.55.0",
+        "@gjsify/web-polyfills": "^0.55.0",
+        "@gjsify/workspace": "^0.55.0",
         "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.54.0",
+        "@gjsify/unit": "^0.55.0",
         "@types/yargs": "^17.0.35",
         "typescript": "^6.0.3"
     },
     "peerDependencies": {
-        "@gjsify/oxfmt-native": "^0.54.0",
-        "@gjsify/rolldown-native": "^0.54.0"
+        "@gjsify/oxfmt-native": "^0.55.0",
+        "@gjsify/rolldown-native": "^0.55.0"
     },
     "peerDependenciesMeta": {
         "@gjsify/oxfmt-native": {