@runfile/cli 1.7.1 → 1.8.0

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/README.md CHANGED
@@ -678,9 +678,30 @@ end
678
678
 
679
679
  ### Stopping early
680
680
 
681
- `exit()` ends the run with a status; `error("…")` fails with a message; `confirm("…")` asks, and stops if the
682
- answer is no. Nothing catches any of them: not a `?` fallback, not `.ignore-errors`. A target may forgive a
683
- command that failed, but being told to stop is not that.
681
+ `exit()` ends the target it is written in, with a status — 0 when none is given. Nothing inside that target
682
+ catches it: not a `?` fallback, not `.ignore-errors`, not a `retry`. A target may forgive a command that failed,
683
+ but being told to stop is not that. It is also how a helper finishes early:
684
+
685
+ ```sh
686
+ # runfiles/_setup-build.run
687
+ # Prepare the toolchain; Linux needs nothing
688
+
689
+ if RUN.os == "linux"
690
+ print("no setup needed")
691
+ exit()
692
+ end
693
+
694
+ $ ./scripts/setup-toolchain.sh
695
+ ```
696
+
697
+ To a target that ran it, the status is how it went — exactly what `$ run _setup-build` would make of it. After a
698
+ 0, the `run _setup-build` line is done and the next line runs. Anything else fails that `run` line, like a
699
+ command that failed: `.ignore-errors` forgives it, `retry` has another go, `code_of` scores it, and if nothing
700
+ handles it, the whole run ends with that status.
701
+
702
+ `error("…")` fails with a message, the way a command fails, so a `?` falls back from it and `.ignore-errors`
703
+ forgives it. `confirm("…")` asks, and stops the whole run if the answer is no. Nothing catches that, not even a
704
+ target that ran this one.
684
705
 
685
706
  `confirm` is a function rather than a property, so the question can depend on what is about to happen — and is
686
707
  skipped by `-y`, in CI, and under `--dry-run`, where there is nothing to approve.
@@ -972,8 +993,9 @@ error: `setup` has never been run
972
993
  run setup
973
994
  ```
974
995
 
975
- It re-triggers when `setup.run` itself changes, so a new dependency is not silently missed. `--dry-run` is
976
- exempt, CI is exempt, and `RUNFILE_SKIP_PREPARE=1` bypasses it.
996
+ Only a setup that succeeded counts: one that failed, or ended with a non-zero `exit()`, leaves the gate shut. It
997
+ re-triggers when `setup.run` itself changes, so a new dependency is not silently missed. `--dry-run` is exempt,
998
+ CI is exempt, and `RUNFILE_SKIP_PREPARE=1` bypasses it.
977
999
 
978
1000
  The record lives in `state.json` in the platform state directory. In CI there is none: a runner is built and
979
1001
  thrown away, so there is no earlier session whose `setup` this one could be relying on — the gate is not
@@ -1154,8 +1176,9 @@ Shell is still there. It is just marked.
1154
1176
  | macOS | Intel, Apple Silicon |
1155
1177
  | Windows | x86-64, arm64 |
1156
1178
 
1157
- `$` lines use bash where it exists, Git Bash on Windows, and `sh` otherwise — so one file works everywhere. Set
1158
- `.shell` to pin one of the other POSIX shells, or name any other interpreter with `exec`.
1179
+ `$` lines use bash where it exists, Git Bash on Windows, and `sh` otherwise — so one file works everywhere. On
1180
+ Windows that is never WSL's `bash.exe`, and neither is `.shell = "bash"` or `exec bash`. Set `.shell` to pin one
1181
+ of the other POSIX shells, or name any other interpreter with `exec`.
1159
1182
 
1160
1183
  ## License
1161
1184
 
Binary file
Binary file
Binary file
package/bin/linux-x64/run CHANGED
Binary file
Binary file
Binary file
package/package.json CHANGED
@@ -13,5 +13,5 @@
13
13
  "license": "MIT",
14
14
  "name": "@runfile/cli",
15
15
  "repository": "https://github.com/JoaaoVerona/runfile",
16
- "version": "1.7.1"
16
+ "version": "1.8.0"
17
17
  }