@basou/cli 0.44.0 → 0.45.0

package/dist/program.d.ts

@@ -1,6 +1,38 @@
 import { Command } from 'commander';
 
+type BuildStamp = {
+    version: string;
+    commit: string;
+    committedAt: string;
+};
+/** The build's own record of itself, or `undefined` when running from source. */
+declare const BASOU_BUILD: BuildStamp | undefined;
+/**
+ * The version of the code that is RUNNING.
+ *
+ * This used to read `package.json` at runtime, on the reasoning that a constant
+ * could go stale past a package bump — true, and it fixed that. But it answers
+ * with what the SOURCE says, and source moves without a rebuild: `git pull` or
+ * `git checkout` leaves `dist` untouched while `package.json` advances. One
+ * workspace ran a build a release and a half behind for a full day while
+ * `--version` confidently reported the newest release, because the built code
+ * and the number it printed came from different places.
+ *
+ * So the built bundle answers from its own stamp, and only a source checkout —
+ * where the source IS the running code — falls back to `package.json`. Neither
+ * reading can now disagree with what is executing.
+ */
 declare const BASOU_CLI_VERSION: string;
+/**
+ * What `--version` prints. The version stays the FIRST token, so anything
+ * parsing the old single-line output with `cut`/`awk` keeps working, and the
+ * build identity follows it.
+ *
+ * The commit is the part that carries the information: two builds of the same
+ * version number are exactly the case that went unnoticed, and the version
+ * alone cannot tell them apart.
+ */
+declare const BASOU_VERSION_LINE: string;
 /**
  * Build the fully-registered `basou` command tree WITHOUT parsing argv.
  *
@@ -12,4 +44,4 @@ declare const BASOU_CLI_VERSION: string;
  */
 declare function buildProgram(): Command;
 
-export { BASOU_CLI_VERSION, buildProgram };
+export { BASOU_BUILD, BASOU_CLI_VERSION, BASOU_VERSION_LINE, buildProgram };