dollar-shell 1.2.0 → 1.2.1

package/README.md

@@ -223,9 +223,11 @@ The rest is identical to `$`: `$sh`, `$sh.from`, `$sh.to` and `$sh.io`/`$sh.thro
 
 Each runtime uses its own backend by default (`node:child_process` on Node, `Bun.spawn` on Bun,
 `Deno.Command` on Deno). Set the **`DSH_FORCE_NODE` environment variable** (e.g. `DSH_FORCE_NODE=1`) to
-force every runtime onto the Node backend — Bun and Deno then run on their `node:child_process`
-compatibility layer. This is handy for sidestepping runtime-specific quirks (e.g. Bun intermittently
-dropping the last chunk of a child's piped output).
+make every runtime spawn through the Node backend — Bun and Deno then run `node:child_process` on
+their compatibility layer. This swaps **only the spawn mechanism**: the runtime that runs your code and how
+it's re-launched stay native, so a forced child of Bun/Deno is still `bun run …` / `deno run …`, never a
+bare `node`. Handy for sidestepping runtime-specific quirks (e.g. Bun intermittently dropping the last
+chunk of a child's piped output).
 
 Because dollar-shell spawns children with `env` defaulting to `process.env`, the variable is inherited by
 those children — so it forces the Node backend across the whole process tree. To force **only the
@@ -248,8 +250,8 @@ sp.stdout.pipe(process.stdout); // sp.stdout is a Node Readable
 
 The API is identical to the main entry — same `$`, `$$`, `$sh`, `shell`, helpers, and
 `.from`/`.to`/`.through`/`.io` — only the stream types differ (`stdin` is a Node `Writable`, `stdout`/`stderr`
-are Node `Readable`s, and `asDuplex` / `.io` / `.through` return a Node `Duplex`). It always uses the Node backend, so it also runs on Bun and Deno through their
-`node:child_process` compatibility layer.
+are Node `Readable`s, and `asDuplex` / `.io` / `.through` return a Node `Duplex`). It always spawns through the Node backend, so it also runs on Bun and Deno through their
+`node:child_process` compatibility layer (only the spawn mechanism changes — the runtime launch stays native).
 
 ## For AI Agents
 
@@ -269,6 +271,7 @@ BSD-3-Clause
 
 ## Release History
 
+- 1.2.1 _Bugfix: `DSH_FORCE_NODE` and `dollar-shell/node` now switch only the spawn mechanism — spawned children stay native (`bun run …` / `deno run …`)._
 - 1.2.0 _Added `dollar-shell/node` with Node streams and a `DSH_FORCE_NODE` flag to force the Node backend on any runtime._
 - 1.1.14 _Fixed Bun stdin abort path, added js-check, Bun + Deno wired into CI._
 - 1.1.13 _Updated dev dependencies._

package/llms-full.txt

@@ -318,12 +318,14 @@ Works on Node.js, Deno, and Bun. The appropriate spawn implementation is selecte
 
 ### Forcing the Node backend
 
-By default each runtime uses its own backend (`node:child_process` on Node, `Bun.spawn` on Bun, `Deno.Command` on Deno). Force every runtime onto the Node backend — so Bun and Deno run on their `node:child_process` compatibility layer — with the **`DSH_FORCE_NODE` environment variable** (any value except `''`, `0`, `false`):
+By default each runtime uses its own backend (`node:child_process` on Node, `Bun.spawn` on Bun, `Deno.Command` on Deno). Make every runtime spawn through the Node backend — so Bun and Deno run `node:child_process` on their compatibility layer — with the **`DSH_FORCE_NODE` environment variable** (any value except `''`, `0`, `false`):
 
 ```bash
 DSH_FORCE_NODE=1 node app.js
 ```
 
+This swaps **only the spawn mechanism**. The runtime that executes your scripts and the way dollar-shell re-launches the current runtime (`currentExecPath` / `runFileArgs` / `cwd`) stay native — a forced child of Bun or Deno is still launched as `bun run …` / `deno run …`, never a bare `node`.
+
 dollar-shell's `env` option defaults to `process.env`, so spawned children inherit the variable — the environment variable therefore forces the Node backend across the **whole process tree** (this process and every dollar-shell child it spawns), which is usually what you want for a build script or wrapper.
 
 To force **only the current process** without leaking into the children it spawns, set the process-local flag instead. It requires a dynamic `import()`, because the backend is chosen once, when the module first loads:
@@ -345,4 +347,4 @@ The package also ships a Node-streams facade at `dollar-shell/node`:
 import {$, $$, $sh, shell, sh, spawn} from 'dollar-shell/node';
 ```
 
-The API is identical to the main entry, except the streams are Node streams (from `node:stream`) instead of Web streams: `stdin`/`stdout`/`stderr` are a Node `Writable`/`Readable`, and `.io`/`.through`/`asDuplex` return a Node `Duplex` (so a process drops straight into a `.pipe()` chain or `stream.pipeline()`). This is convenient for direct Node-ecosystem interop — pipe straight into `fs`/`zlib`/etc. with no Web↔Node adapter, and skip the conversion. It always uses the Node backend, so on Bun and Deno it runs through their `node:child_process` compatibility layer. Type declarations live in `src/node/index.d.ts`.
+The API is identical to the main entry, except the streams are Node streams (from `node:stream`) instead of Web streams: `stdin`/`stdout`/`stderr` are a Node `Writable`/`Readable`, and `.io`/`.through`/`asDuplex` return a Node `Duplex` (so a process drops straight into a `.pipe()` chain or `stream.pipeline()`). This is convenient for direct Node-ecosystem interop — pipe straight into `fs`/`zlib`/etc. with no Web↔Node adapter, and skip the conversion. It always spawns through the Node backend, so on Bun and Deno it runs `node:child_process` through their compatibility layer; like `DSH_FORCE_NODE`, this changes only the spawn mechanism — the runtime that executes your scripts and how it is re-launched stay native. Type declarations live in `src/node/index.d.ts`.

package/llms.txt

@@ -65,11 +65,11 @@ await $sh({stdout: 'inherit'})`echo ${raw('"hello"')}`;
 
 ## Forcing the Node backend
 
-By default each runtime uses its native backend. Set the `DSH_FORCE_NODE` environment variable (e.g. `DSH_FORCE_NODE=1`) to force the Node backend on every runtime (Bun and Deno then run on their `node:child_process` compat). Because dollar-shell's `env` option defaults to `process.env`, spawned children inherit the variable, so it forces the whole process tree; to force only the current process (no leak to children), set `globalThis.DSH_FORCE_NODE = true` before a dynamic `import()` instead (process-local). Useful to sidestep runtime-specific quirks. The backend is selected once, at import time. Treated as off: unset, `''`, `0`, `false`.
+By default each runtime uses its native backend. Set the `DSH_FORCE_NODE` environment variable (e.g. `DSH_FORCE_NODE=1`) to make every runtime spawn through the Node backend (`node:child_process`; Bun and Deno run it on their Node compat). This swaps **only the spawn mechanism** — the runtime that runs your code and how dollar-shell re-launches it stay native, so a forced child of Bun/Deno is still `bun run …` / `deno run …`, never a bare `node`. Because dollar-shell's `env` option defaults to `process.env`, spawned children inherit the variable, so it forces the whole process tree; to force only the current process (no leak to children), set `globalThis.DSH_FORCE_NODE = true` before a dynamic `import()` instead (process-local). Useful to sidestep runtime-specific quirks. The backend is selected once, at import time. Treated as off: unset, `''`, `0`, `false`.
 
 ## Node streams (`dollar-shell/node`)
 
-`import {$, $$, $sh, shell, spawn} from 'dollar-shell/node'` gives the identical API, but `stdin`/`stdout`/`stderr` are Node `Readable`/`Writable` (and `.io`/`.through`/`asDuplex` a Node `Duplex`) instead of Web streams — for direct Node-ecosystem piping with no adapter. Always uses the Node backend (runs on Bun/Deno via their `node:child_process` compat).
+`import {$, $$, $sh, shell, spawn} from 'dollar-shell/node'` gives the identical API, but `stdin`/`stdout`/`stderr` are Node `Readable`/`Writable` (and `.io`/`.through`/`asDuplex` a Node `Duplex`) instead of Web streams — for direct Node-ecosystem piping with no adapter. Always spawns through the Node backend (`node:child_process`, run on Bun/Deno via their Node compat); only the spawn mechanism changes — the runtime launch stays native.
 
 ## Docs
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "dollar-shell",
   "description": "Run OS and shell commands using template tag functions. Same API in Node, Deno, and Bun. Web streams, TypeScript typings, zero dependencies.",
-  "version": "1.2.0",
+  "version": "1.2.1",
   "type": "module",
   "main": "./src/index.js",
   "types": "./src/index.d.ts",
@@ -77,7 +77,7 @@
     "@types/deno": "^2.7.0",
     "@types/node": "^25.9.1",
     "prettier": "^3.8.3",
-    "tape-six": "^1.10.0",
+    "tape-six": "^1.10.1",
     "typescript": "^6.0.3"
   },
   "tape6": {

package/src/index.js

@@ -35,16 +35,21 @@ const envForceNode = () => {
 const forceNode =
   isFlagOn(/** @type {any} */ (globalThis).DSH_FORCE_NODE) || isFlagOn(envForceNode());
 
-let modSpawn;
-if (forceNode) {
-  modSpawn = await import('./spawn/node.js');
-} else if (typeof Deno !== 'undefined') {
-  modSpawn = await import('./spawn/deno.js');
+// The runtime-native backend defines how to launch *this* runtime — `currentExecPath`,
+// `runFileArgs`, `cwd`. DSH_FORCE_NODE forces only the spawn *implementation*
+// (`node:child_process`); it must not change which runtime we target or how it is
+// invoked, so a forced child of Bun/Deno is still `bun run …` / `deno run …`, never a
+// bare `node`. (`process.execPath` is already the real runtime under Bun/Deno node
+// compat; `runFileArgs` is what actually differs — `[]` for node vs `['run']`.)
+let modRuntime;
+if (typeof Deno !== 'undefined') {
+  modRuntime = await import('./spawn/deno.js');
 } else if (typeof Bun !== 'undefined') {
-  modSpawn = await import('./spawn/bun.js');
+  modRuntime = await import('./spawn/bun.js');
 } else {
-  modSpawn = await import('./spawn/node.js');
+  modRuntime = await import('./spawn/node.js');
 }
+const modSpawn = forceNode ? await import('./spawn/node.js') : modRuntime;
 
 export const {
   spawn,
@@ -59,6 +64,11 @@ export const {
   shell,
   sh,
   $sh
-} = await buildApi(modSpawn);
+} = await buildApi({
+  spawn: modSpawn.spawn,
+  cwd: modRuntime.cwd,
+  currentExecPath: modRuntime.currentExecPath,
+  runFileArgs: modRuntime.runFileArgs
+});
 
 export default $;

package/src/node/index.js

@@ -2,13 +2,26 @@
 
 // The Node-streams facade: identical API to the main entry, but stdin/stdout/stderr
 // (and .from/.to/.through/.io/asDuplex) are Node streams instead of Web streams.
-// Always uses the Node backend — on Bun/Deno it runs through their node:child_process compat.
+// Spawning always goes through node:child_process (on Bun/Deno via their node compat) —
+// that is the point of this entry. But, like DSH_FORCE_NODE on the main entry, this must
+// affect only the spawn implementation: `currentExecPath` / `runFileArgs` / `cwd` stay
+// runtime-native, so a child of Bun/Deno is still launched as `bun run …` / `deno run …`,
+// never a bare `node`.
 
 import {buildApi} from '../build.js';
 import * as backend from '../spawn/node.js';
 
 export {isWindows, raw, winCmdEscape} from '../utils.js';
 
+let modRuntime;
+if (typeof Deno !== 'undefined') {
+  modRuntime = await import('../spawn/deno.js');
+} else if (typeof Bun !== 'undefined') {
+  modRuntime = await import('../spawn/bun.js');
+} else {
+  modRuntime = backend;
+}
+
 export const {
   spawn,
   cwd,
@@ -24,9 +37,9 @@ export const {
   $sh
 } = await buildApi({
   spawn: backend.nodeStreamSpawn,
-  cwd: backend.cwd,
-  currentExecPath: backend.currentExecPath,
-  runFileArgs: backend.runFileArgs
+  cwd: modRuntime.cwd,
+  currentExecPath: modRuntime.currentExecPath,
+  runFileArgs: modRuntime.runFileArgs
 });
 
 export default $;