@saastemly/voidcommerce 0.15.0 → 0.16.1

package/dist/cli.js

@@ -21,7 +21,7 @@ import {
   runVoid,
   version,
   voidAppsIn
-} from "./index-jycz3x3g.js";
+} from "./index-w0c96dxv.js";
 import {
   LOCAL_KEY_FILE,
   PRIVATE_KEY_VAR,

package/dist/{index-jycz3x3g.js → index-w0c96dxv.js}

@@ -1379,7 +1379,7 @@ import color from "picocolors";
 // package.json
 var package_default = {
   name: "@saastemly/voidcommerce",
-  version: "0.15.0",
+  version: "0.16.1",
   description: "Void, with a shop in it. `vc init` walks you through Better Auth, betterCommerce and every plugin; everything else passes through to `void`.",
   type: "module",
   license: "MIT",
@@ -1712,8 +1712,10 @@ function renderDistWorkflow(manifest) {
 
 # Generated by \`vc init\` from voidcommerce.json.
 #
-# A push to main regenerates the Void app from the manifest, publishes it to
-# \`${DIST_BRANCH}\` as a standalone tree, and deploys it to Cloudflare.
+# A push to main is checked, then regenerates the Void app from the manifest,
+# publishes it to \`${DIST_BRANCH}\` as a standalone tree, and deploys it to
+# Cloudflare. The check runs FIRST and on its own: nothing is built, created
+# or replaced for a shop that is not ready.
 #
 # The credentials come from the repository, set once by \`vc link\`:
 #
@@ -1738,8 +1740,32 @@ permissions:
   contents: write
 
 jobs:
+  # ── Is what was just pushed fit to deploy? ─────────────────────────────
+  #
+  # First, and on its own, because everything after it costs something: a
+  # build, a database, a worker replaced. It answers the question the deploy
+  # would ask, against exactly what was pushed, and needs NO CREDENTIALS to
+  # do it — config lives in the repository, encrypted, so readiness is a
+  # property of the commit rather than of whoever pushed it.
+  #
+  # This is the gate. It cannot be skipped with --no-verify, and it runs the
+  # same way for every push and every person.
+  preflight:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+      - uses: oven-sh/setup-bun@v2
+      - run: bun install --frozen-lockfile
+
+      # Every required key actually SET rather than merely declared, nothing
+      # committed in the clear, the hostnames the manifest says, and no
+      # migration generated but left uncommitted.
+      - name: vc preflight --repo
+        run: bunx vc preflight --repo
+
   # ── Regenerate, and publish the standalone tree ────────────────────────
   dist:
+    needs: preflight
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v6
@@ -1839,7 +1865,12 @@ regenerate with \`vc generate\`.
 git push
 \`\`\`
 
-That is the deploy. GitHub Actions regenerates the app from
+That is the deploy. It is checked first: a \`preflight\` job runs before
+anything is built, and refuses a shop whose secrets are declared but unset,
+whose values were committed in the clear, or whose migrations are not all
+committed. It needs no credentials — readiness is a property of the commit,
+not of the machine that pushed it — so it fails the same way for everyone,
+and cannot be skipped. GitHub Actions regenerates the app from
 \`voidcommerce.json\`, publishes a standalone copy to \`${DIST_BRANCH}\`, creates the
 database and queue if they are not there, applies the migrations, and deploys
 the worker with this repository's secrets attached.
@@ -2449,25 +2480,7 @@ async function generateHooks(root, result) {
 # history and has to be treated as burned.
 bunx vc guard
 `, result, "regenerate");
-  await put(root, ".husky/pre-push", `#!/usr/bin/env sh
-# Generated by \`vc init\`.
-#
-# Pushing main deploys this shop, so the same checks the deploy would make
-# run here first — where you can read the error and fix it, rather than in a
-# build log after the shop is already updating.
-#
-# Needs no credentials: it reads only what is committed.
-# To push anyway, deliberately: git push --no-verify
-
-while read -r _local_ref _local_sha remote_ref _remote_sha; do
-  case "$remote_ref" in
-    refs/heads/main|refs/heads/master)
-      echo "vc: main is the deploy branch — checking what you are about to publish"
-      bunx vc preflight --repo || exit 1
-      ;;
-  esac
-done
-`, result, "regenerate");
+  await retire(root, ".husky/pre-push", result);
 }
 async function generate(root, manifest) {
   const result = { written: [], kept: [], retired: [], packages: packagesOf(manifest) };

package/dist/index.js

@@ -52,7 +52,7 @@ import {
   routeProblem,
   strictDependencies,
   upsertJsonc
-} from "./index-jycz3x3g.js";
+} from "./index-w0c96dxv.js";
 import {
   allEnvKeys,
   envSummary,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@saastemly/voidcommerce",
-  "version": "0.15.0",
+  "version": "0.16.1",
   "description": "Void, with a shop in it. `vc init` walks you through Better Auth, betterCommerce and every plugin; everything else passes through to `void`.",
   "type": "module",
   "license": "MIT",

package/src/deploy/index.ts

@@ -66,11 +66,14 @@ export async function preflightCommand(args: string[]): Promise<number> {
 	printPreflight(project, result, source);
 	if (source !== "repository") return result.ready ? 0 : 1;
 
-	// A repository check is a check on what will be PUSHED, so it also asks
-	// the question CI would ask and cannot answer any earlier: is there a
-	// migration that was generated and never committed? Applied under a fresh
-	// name on the next run, against tables that already exist, it fails the
-	// deploy — and it fails it after the shop is already down for the update.
+	// Is there a migration that was generated and never committed?
+	//
+	// This one has teeth only LOCALLY. A CI checkout is by definition clean,
+	// so `git status` there reports nothing and this passes vacuously — the
+	// job that actually catches it in CI is the one that runs AFTER `vc dist`
+	// regenerates, because that is the moment a new migration can appear.
+	// Both are kept: they catch the same mistake at the two different moments
+	// it can be made.
 	const pending = await uncommittedMigrations(project.root);
 	if (pending.length > 0) {
 		console.error(

package/src/generate/ci.ts

@@ -42,8 +42,10 @@ export function renderDistWorkflow(manifest: Manifest): string {
 
 # Generated by \`vc init\` from voidcommerce.json.
 #
-# A push to main regenerates the Void app from the manifest, publishes it to
-# \`${DIST_BRANCH}\` as a standalone tree, and deploys it to Cloudflare.
+# A push to main is checked, then regenerates the Void app from the manifest,
+# publishes it to \`${DIST_BRANCH}\` as a standalone tree, and deploys it to
+# Cloudflare. The check runs FIRST and on its own: nothing is built, created
+# or replaced for a shop that is not ready.
 #
 # The credentials come from the repository, set once by \`vc link\`:
 #
@@ -68,8 +70,32 @@ permissions:
   contents: write
 
 jobs:
+  # ── Is what was just pushed fit to deploy? ─────────────────────────────
+  #
+  # First, and on its own, because everything after it costs something: a
+  # build, a database, a worker replaced. It answers the question the deploy
+  # would ask, against exactly what was pushed, and needs NO CREDENTIALS to
+  # do it — config lives in the repository, encrypted, so readiness is a
+  # property of the commit rather than of whoever pushed it.
+  #
+  # This is the gate. It cannot be skipped with --no-verify, and it runs the
+  # same way for every push and every person.
+  preflight:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+      - uses: oven-sh/setup-bun@v2
+      - run: bun install --frozen-lockfile
+
+      # Every required key actually SET rather than merely declared, nothing
+      # committed in the clear, the hostnames the manifest says, and no
+      # migration generated but left uncommitted.
+      - name: vc preflight --repo
+        run: bunx vc preflight --repo
+
   # ── Regenerate, and publish the standalone tree ────────────────────────
   dist:
+    needs: preflight
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v6
@@ -171,7 +197,12 @@ regenerate with \`vc generate\`.
 git push
 \`\`\`
 
-That is the deploy. GitHub Actions regenerates the app from
+That is the deploy. It is checked first: a \`preflight\` job runs before
+anything is built, and refuses a shop whose secrets are declared but unset,
+whose values were committed in the clear, or whose migrations are not all
+committed. It needs no credentials — readiness is a property of the commit,
+not of the machine that pushed it — so it fails the same way for everyone,
+and cannot be skipped. GitHub Actions regenerates the app from
 \`voidcommerce.json\`, publishes a standalone copy to \`${DIST_BRANCH}\`, creates the
 database and queue if they are not there, applies the migrations, and deploys
 the worker with this repository's secrets attached.

package/src/generate/index.ts

@@ -229,46 +229,10 @@ bunx vc guard
 		result,
 		"regenerate",
 	);
-	/**
-	 * Pushing main IS the deploy, so this is the last moment anything is
-	 * checked by someone who can read the error.
-	 *
-	 * Everything the deploy needs is in the repository — that is the whole
-	 * point of keeping config in the environment — so the check needs no
-	 * credentials and runs anywhere. It asks the questions CI cannot answer
-	 * until it is too late to matter: is every required key actually SET
-	 * rather than merely declared, is anything committed in the clear, do the
-	 * hostnames match the manifest, is a migration missing.
-	 *
-	 * Only for main. Pushing a branch is not a deploy, and gating it would
-	 * teach people to reach for --no-verify, which turns the gate off for the
-	 * push that does matter.
-	 */
-	await put(
-		root,
-		".husky/pre-push",
-		`#!/usr/bin/env sh
-# Generated by \`vc init\`.
-#
-# Pushing main deploys this shop, so the same checks the deploy would make
-# run here first — where you can read the error and fix it, rather than in a
-# build log after the shop is already updating.
-#
-# Needs no credentials: it reads only what is committed.
-# To push anyway, deliberately: git push --no-verify
-
-while read -r _local_ref _local_sha remote_ref _remote_sha; do
-  case "$remote_ref" in
-    refs/heads/main|refs/heads/master)
-      echo "vc: main is the deploy branch — checking what you are about to publish"
-      bunx vc preflight --repo || exit 1
-      ;;
-  esac
-done
-`,
-		result,
-		"regenerate",
-	);
+	// The pre-PUSH gate lives in CI now: the deploy runs off-machine, so the
+	// authoritative check belongs there, where nobody can --no-verify past it.
+	// See renderDistWorkflow.
+	await retire(root, ".husky/pre-push", result);
 }
 
 export async function generate(root: string, manifest: Manifest): Promise<GenerateResult> {