@fusion.dev/helix-cli 0.34.1 → 0.35.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.
Files changed (2) hide show
  1. package/bin.mjs +24 -2
  2. package/package.json +6 -6
package/bin.mjs CHANGED
@@ -18,8 +18,10 @@
18
18
  * shared target is common and guessing `./target` would miss it. Then the
19
19
  * binary npm installed beside this, which is what a consumer has: after the
20
20
  * target, so a checkout runs what it built rather than a binary a release once
21
- * placed. Then whatever is on `PATH`. Only then a build, and only in this
22
- * repository, the one place there is a crate to build.
21
+ * placed. Then whatever is on `PATH`, named out loud in a checkout, because a
22
+ * binary from somewhere else is about to answer questions about this tree. Only
23
+ * then a build, and only in this repository, the one place there is a crate to
24
+ * build.
23
25
  *
24
26
  * **A build is a fallback and not the plan.** It happens once, prints that it
25
27
  * is happening, and a CI pipeline that has already run `cargo build` never
@@ -191,6 +193,26 @@ if (found && existsSync(found)) {
191
193
  probed: see `onPath`, where the probe this used to do is what recursed. */
192
194
  const installed = onPath()
193
195
  if (installed) {
196
+ /* **In a checkout, say which binary this is before running it.** Getting here
197
+ means no `target/`, no platform package and no cargo, so what runs is
198
+ whatever some earlier install left on the path, and it answers about this
199
+ tree while knowing nothing about it. Measured 14 Sep 2026 in a fresh clone:
200
+ a `~/.cargo/bin/helix` from August read the configuration file under its
201
+ previous name and reported "no configuration", which reads as a fault in
202
+ the checkout and is a fault in the binary that was asked.
203
+
204
+ It still runs, because an installed binary is the only one there is and
205
+ refusing would leave a machine with no Rust unable to run any check at all.
206
+ What changes is that the answer is attributed. Only in a checkout: for a
207
+ consumer, a binary on `PATH` is the ordinary way to have one. */
208
+ if (checkout) {
209
+ console.error(
210
+ `helix: nothing built here, so running \`${installed}\` from PATH.\n` +
211
+ ' It was not built from this checkout and need not agree with it.\n' +
212
+ ' Install a Rust toolchain to build the one this tree defines, or point\n' +
213
+ ' `HELIX_BIN` at the binary to run.',
214
+ )
215
+ }
194
216
  run(installed)
195
217
  }
196
218
 
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@fusion.dev/helix-cli",
3
3
  "description": "The Helix command line, for a workspace that reaches it through npm.",
4
- "version": "0.34.1",
4
+ "version": "0.35.0",
5
5
  "license": "MIT",
6
6
  "author": "Ross Sheppard <ross.sheppard@fusion.dev>",
7
7
  "repository": {
@@ -29,11 +29,11 @@
29
29
  "theme"
30
30
  ],
31
31
  "optionalDependencies": {
32
- "@fusion.dev/helix-cli-darwin-arm64": "0.34.1",
33
- "@fusion.dev/helix-cli-darwin-x64": "0.34.1",
34
- "@fusion.dev/helix-cli-linux-arm64": "0.34.1",
35
- "@fusion.dev/helix-cli-linux-x64": "0.34.1",
36
- "@fusion.dev/helix-cli-win32-x64": "0.34.1"
32
+ "@fusion.dev/helix-cli-darwin-arm64": "0.35.0",
33
+ "@fusion.dev/helix-cli-darwin-x64": "0.35.0",
34
+ "@fusion.dev/helix-cli-linux-arm64": "0.35.0",
35
+ "@fusion.dev/helix-cli-linux-x64": "0.35.0",
36
+ "@fusion.dev/helix-cli-win32-x64": "0.35.0"
37
37
  },
38
38
  "publishConfig": {
39
39
  "access": "restricted"