@better-update/cli 0.41.0 → 0.41.1

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.
package/dist/index.mjs CHANGED
@@ -35,7 +35,7 @@ var __require = /* @__PURE__ */ createRequire(import.meta.url);
35
35
 
36
36
  //#endregion
37
37
  //#region package.json
38
- var version = "0.41.0";
38
+ var version = "0.41.1";
39
39
 
40
40
  //#endregion
41
41
  //#region src/lib/interactive-mode.ts
@@ -20081,6 +20081,50 @@ const initGitRepo = (stagingRoot) => Effect.tryPromise({
20081
20081
  catch: (cause) => new StagingError({ message: `Failed to init git repo in staging dir: ${formatCause(cause)}` })
20082
20082
  }).pipe(Effect.asVoid);
20083
20083
  /**
20084
+ * Snapshot the staged tree as a single commit so its working tree reads CLEAN.
20085
+ *
20086
+ * EAS stages via `git clone` + checkout, so the tree it hands to
20087
+ * `expo prebuild --clean` is a clean checkout. Our `cp` + `git init` leaves
20088
+ * every staged file UNTRACKED, which `expo prebuild`'s git check reads as
20089
+ * "dirty" (`git status --porcelain` is non-empty). Because the native build
20090
+ * runs inside a PTY, Expo's `isInteractive()` is true even with no real
20091
+ * controlling TTY, so it prompts `Continue with uncommitted changes?` and then
20092
+ * blocks on stdin we never write — hanging CI / backgrounded / piped builds.
20093
+ *
20094
+ * Committing once here makes `git status` clean, so Expo's check passes on
20095
+ * EVERY Expo version — the `EXPO_NO_GIT_STATUS` env gate the build sets only
20096
+ * exists in newer Expo — with no global `CI=1` side effects. The real
20097
+ * dirty-tree decision already ran against the user's *actual* working tree in
20098
+ * `ensureRepoClean` (honoring `--allow-dirty`). Best-effort: hooks are disabled
20099
+ * and a failure is non-fatal — the build proceeds and `EXPO_NO_GIT_STATUS`
20100
+ * still covers newer Expo.
20101
+ */
20102
+ const commitStagingSnapshot = (stagingRoot) => Effect.tryPromise(async () => {
20103
+ const run = async (args) => execFileAsync$1("git", [...args], {
20104
+ cwd: stagingRoot,
20105
+ env: {
20106
+ ...process.env,
20107
+ LEFTHOOK: "0",
20108
+ HUSKY: "0"
20109
+ }
20110
+ });
20111
+ await run(["add", "-A"]);
20112
+ await run([
20113
+ "-c",
20114
+ "user.name=better-update",
20115
+ "-c",
20116
+ "user.email=build@better-update.dev",
20117
+ "-c",
20118
+ "commit.gpgsign=false",
20119
+ "commit",
20120
+ "--no-verify",
20121
+ "--allow-empty",
20122
+ "-q",
20123
+ "-m",
20124
+ "better-update staging snapshot"
20125
+ ]);
20126
+ }).pipe(Effect.ignore);
20127
+ /**
20084
20128
  * Install args per package manager, frozen-lockfile variants matching EAS
20085
20129
  * (`bun install --frozen-lockfile` / `npm ci --include=dev` / etc.) so the
20086
20130
  * staged install resolves exactly what the user's lockfile pins.
@@ -20136,6 +20180,7 @@ const prepareStagingProject = (input) => Effect.gen(function* () {
20136
20180
  env: commandEnv
20137
20181
  });
20138
20182
  } else yield* printHuman("No package.json at the staging root — skipping dependency install.");
20183
+ yield* commitStagingSnapshot(stagingRoot);
20139
20184
  return {
20140
20185
  stagingRoot,
20141
20186
  projectRoot,