@saastemly/voidcommerce 0.16.0 → 0.16.1

package/dist/cli.js

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

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

@@ -1379,7 +1379,7 @@ import color from "picocolors";
 // package.json
 var package_default = {
   name: "@saastemly/voidcommerce",
-  version: "0.16.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/dist/index.js

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@saastemly/voidcommerce",
-  "version": "0.16.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(