@lark-codem/codem-core 0.8.2 → 0.8.3

package/bin/lib/control-fd.js

@@ -0,0 +1,63 @@
+"use strict";
+
+// codem-bridge launches linco with FOUR stdio slots, not three:
+//
+//   stdio: ["inherit", "inherit", "inherit", "pipe"]   (codem-bridge linco-runner.js)
+//            \______ the terminal ______/    \_ the /space control channel
+//
+// fd 3 is an out-of-band channel: on a `/space` selection linco writes one NDJSON
+// line to it so codem-bridge can persist the chosen project without polluting the
+// TUI's screen. The host announces the fd number via `CODEM_PROJECT_CHANNEL_FD`.
+//
+// This shim sits BETWEEN the two processes, and `stdio: "inherit"` is shorthand for
+// ["inherit","inherit","inherit"] — exactly three slots. It therefore dropped fd 3
+// on the floor while still forwarding the env var that advertises it, so linco kept
+// writing to a fd the exec'd process no longer held (ENXIO, not EBADF: libuv fills
+// unlisted slots with an unusable placeholder rather than leaving them closed).
+//
+// All three layers then failed quietly — linco's writer is best-effort and only
+// `tracing::warn!`s, and on the host side an idle pipe is indistinguishable from
+// "an old linco that never writes fd 3" (codem-bridge says so in a comment). Net
+// effect: `/space` reported success and the selection was silently lost.
+//
+// SCOPE — unix only. linco's writer is a `#[cfg(not(unix))]` no-op on Windows
+// (crates/linco-cli/src/space_channel.rs), so there is nothing to forward there and
+// no reason to perturb Windows process creation.
+
+/// The env var through which codem-bridge advertises the control fd.
+const CONTROL_FD_ENV = "CODEM_PROJECT_CHANNEL_FD";
+
+/// stdio for a plain interactive run: the terminal and nothing else.
+const TERMINAL_STDIO = ["inherit", "inherit", "inherit"];
+
+/// Parse the advertised fd, or null when there is nothing to forward.
+///
+/// Only fd 3 is expressible here: `stdio` slots are positional, so the 4th entry
+/// IS fd 3. A host asking for fd 4+ cannot be honoured by appending one entry, and
+/// silently forwarding the wrong fd would be worse than not forwarding at all.
+function controlFdFromEnv(env) {
+  const raw = env && env[CONTROL_FD_ENV];
+  if (typeof raw !== "string") {
+    return null;
+  }
+  const trimmed = raw.trim();
+  // Number.parseInt would accept "3x"/"3.5"; the host writes a bare integer.
+  if (!/^-?\d+$/.test(trimmed)) {
+    return null;
+  }
+  return Number.parseInt(trimmed, 10) === 3 ? 3 : null;
+}
+
+/// Build the stdio array to hand the platform binary. Returns a fresh array —
+/// `launch` mutates it when degrading after an EBADF.
+function buildStdio({ env = process.env, platform = process.platform } = {}) {
+  if (platform === "win32") {
+    return TERMINAL_STDIO.slice();
+  }
+  if (controlFdFromEnv(env) === null) {
+    return TERMINAL_STDIO.slice();
+  }
+  return [...TERMINAL_STDIO, "inherit"];
+}
+
+module.exports = { buildStdio, controlFdFromEnv, CONTROL_FD_ENV, TERMINAL_STDIO };

package/bin/lib/launch.js

@@ -0,0 +1,106 @@
+"use strict";
+
+// Spawning the platform binary, with the two failure modes that actually reach
+// users spelled out.
+//
+// WHY THIS IS NOT JUST `spawn(...)` + `child.on("error")`:
+// `child_process.spawn` reports ENOENT asynchronously (via the "error" event) but
+// throws SYNCHRONOUSLY for every other errno — see the `throw new ErrnoException(err,
+// 'spawn')` in node:internal/child_process. An `on("error")` handler therefore cannot
+// observe an EACCES/EBADF/UNKNOWN failure, and the user gets a raw Node stack trace
+// naming an internal file instead of a sentence about their own machine. Both paths
+// must funnel into the same reporter.
+
+const { TERMINAL_STDIO } = require("./control-fd");
+
+/// Human-readable follow-up for the errnos we can actually say something useful
+/// about. Anything else falls through to the bare message.
+function hintsFor(code, platform, binary) {
+  switch (code) {
+    case "UNKNOWN":
+      // libuv's catch-all for Win32 errors it has no mapping for. The common
+      // cause in the field is CreateProcessW being denied by security software
+      // (ERROR_VIRUS_INFECTED / ERROR_VIRUS_DELETED have no libuv mapping).
+      return platform === "win32"
+        ? [
+            "On Windows this usually means antivirus or endpoint security software blocked",
+            "the executable, or the file on disk is damaged. Run it directly to see the",
+            "underlying OS error:",
+            `  & "${binary}" --version`,
+          ]
+        : null;
+    case "ENOENT":
+      return [
+        "The platform binary is missing. Reinstall it with:",
+        "  npm install --include=optional @lark-codem/codem-core",
+      ];
+    case "EACCES":
+      return [
+        "The platform binary is not executable. Check its file permissions:",
+        `  ls -l "${binary}"`,
+      ];
+    default:
+      return null;
+  }
+}
+
+function reportFatal({ error, binary, platform, stderr, exit }) {
+  stderr(`linco: failed to launch ${binary}`);
+  stderr(`  ${error && error.message ? error.message : String(error)}`);
+  const hints = hintsFor(error && error.code, platform, binary);
+  if (hints) {
+    for (const line of hints) {
+      stderr(`  ${line}`);
+    }
+  }
+  exit(1);
+}
+
+/// Spawn the platform binary. Returns the child process, or undefined when the
+/// launch failed (the caller has already been told via `exit`).
+///
+/// `stdio` may carry a 4th slot for codem-bridge's /space control fd. If the host
+/// advertised that fd but did not actually pass it, spawning fails with EBADF —
+/// degrade to the terminal-only trio and start anyway rather than refusing to run
+/// over a non-essential side channel.
+function launch({
+  binary,
+  args,
+  stdio,
+  platform = process.platform,
+  spawnImpl = require("node:child_process").spawn,
+  stderr = (line) => console.error(line),
+  exit = (code) => process.exit(code),
+}) {
+  const attempt = (stdioForAttempt) =>
+    spawnImpl(binary, args, { stdio: stdioForAttempt, windowsHide: true });
+
+  let child;
+  try {
+    child = attempt(stdio);
+  } catch (error) {
+    if (stdio.length > 3 && error && error.code === "EBADF") {
+      stderr(
+        "linco: the host advertised a /space control fd it did not pass; continuing without it"
+      );
+      try {
+        child = attempt(TERMINAL_STDIO.slice());
+      } catch (retryError) {
+        reportFatal({ error: retryError, binary, platform, stderr, exit });
+        return undefined;
+      }
+    } else {
+      reportFatal({ error, binary, platform, stderr, exit });
+      return undefined;
+    }
+  }
+
+  // ENOENT lands here instead of in the catch above.
+  child.on("error", (error) => {
+    reportFatal({ error, binary, platform, stderr, exit });
+  });
+
+  return child;
+}
+
+module.exports = { launch, hintsFor };

package/bin/linco

@@ -1,10 +1,11 @@
 #!/usr/bin/env node
 "use strict";
 
-const { spawn } = require("node:child_process");
 const fs = require("node:fs");
 const { detectTarget } = require("./lib/detect-target");
 const { resolvePlatformBinary } = require("./lib/resolve-binary");
+const { buildStdio } = require("./lib/control-fd");
+const { launch } = require("./lib/launch");
 
 function main() {
   let target;
@@ -30,15 +31,17 @@ function main() {
     // best-effort
   }
 
-  const child = spawn(binary, process.argv.slice(2), {
-    stdio: "inherit",
-    windowsHide: true,
-  });
-
-  child.on("error", (error) => {
-    console.error(`linco: failed to spawn ${binary}: ${error.message}`);
-    process.exit(1);
+  // Not a bare `stdio: "inherit"`: that is three slots and would drop the /space
+  // control fd codem-bridge passes as fd 3. See lib/control-fd.js.
+  const child = launch({
+    binary,
+    args: process.argv.slice(2),
+    stdio: buildStdio(),
   });
+  if (!child) {
+    // launch() already reported the failure and called exit(1).
+    return;
+  }
 
   const forwardSignal = (signal) => {
     try {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lark-codem/codem-core",
-  "version": "0.8.2",
+  "version": "0.8.3",
   "description": "CodeM CLI.",
   "license": "SEE LICENSE IN LICENSE",
   "bin": {
@@ -11,15 +11,15 @@
     "LICENSE"
   ],
   "optionalDependencies": {
-    "@lark-codem/codem-core-darwin-arm64": "0.8.2",
-    "@lark-codem/codem-core-darwin-x64": "0.8.2",
-    "@lark-codem/codem-core-linux-arm64-gnu": "0.8.2",
-    "@lark-codem/codem-core-linux-arm64-musl": "0.8.2",
-    "@lark-codem/codem-core-linux-x64-gnu": "0.8.2",
-    "@lark-codem/codem-core-linux-x64-musl": "0.8.2",
-    "@lark-codem/codem-core-win32-arm64-gnu": "0.8.2",
-    "@lark-codem/codem-core-win32-ia32-gnu": "0.8.2",
-    "@lark-codem/codem-core-win32-x64-gnu": "0.8.2"
+    "@lark-codem/codem-core-darwin-arm64": "0.8.3",
+    "@lark-codem/codem-core-darwin-x64": "0.8.3",
+    "@lark-codem/codem-core-linux-arm64-gnu": "0.8.3",
+    "@lark-codem/codem-core-linux-arm64-musl": "0.8.3",
+    "@lark-codem/codem-core-linux-x64-gnu": "0.8.3",
+    "@lark-codem/codem-core-linux-x64-musl": "0.8.3",
+    "@lark-codem/codem-core-win32-arm64-gnu": "0.8.3",
+    "@lark-codem/codem-core-win32-ia32-gnu": "0.8.3",
+    "@lark-codem/codem-core-win32-x64-gnu": "0.8.3"
   },
   "engines": {
     "node": ">=18"