🧪 dnt's npm install aborts with exit 134 during esbuild postinstall in cli-npm-bin

[taras]

scripts/tests/cli-npm-bin.test.ts builds the npm package through build-npm.ts, which runs dnt, which runs npm install in the generated package. That install aborted with exit code 134 (SIGABRT, 128+6) while esbuild's postinstall was pending, failing the suite. The identical revision then passed twice with no code change.

This is recorded so the successful rerun does not hide it. It did not reopen the review slice it appeared in.

Failing command

Run as part of the frozen issue #822 Slice 5 matrix, nine suites in one invocation:

deno task test \
  packages/cli/tests/plugin-cli.test.ts \
  packages/cli/tests/syntax-cli.test.ts \
  packages/cli/tests/plan-component.test.ts \
  packages/git/tests/repository-components.test.ts \
  packages/workflow/tests/generated-agent-component.test.ts \
  packages/workflow/tests/public-entrypoint.test.ts \
  scripts/tests/plugin-compiled.test.ts \
  scripts/tests/cli-npm-bin.test.ts \
  scripts/tests/publish-workflow-membership.test.ts

Result: FAILED | 35 passed (190 steps) | 1 failed (1 step) (3m26s), exit status 1.

Output

npm CLI package ... runs a complete program piped into the emitted bin => https://jsr.io/@std/testing/1.0.17/_test_suite.ts:394:15
error: Error: build-npm.ts exited 1
npm warn allow-scripts 1 package has install scripts not yet covered by allowScripts:
npm warn allow-scripts   esbuild@0.28.2 (postinstall: node install.js)
npm warn allow-scripts
npm warn allow-scripts Run `npm approve-scripts --allow-scripts-pending` to review, or `npm approve-scripts <pkg>` to allow.
npm warn allow-scripts 1 package has install scripts not yet covered by allowScripts:
npm warn allow-scripts   esbuild@0.28.2 (postinstall: node install.js)
npm warn allow-scripts
npm warn allow-scripts Run `npm approve-scripts --allow-scripts-pending` to review, or `npm approve-scripts <pkg>` to allow.
Error: npm install failed with exit code 134
    at runCommand (https://jsr.io/@deno/dnt/0.42.3/lib/utils.ts:56:13)
    at async build (https://jsr.io/@deno/dnt/0.42.3/mod.ts:259:5)

      throw new Error(`build-npm.ts exited ${built.code}\n${built.stderr}`);
            ^
    at scripts/tests/cli-npm-bin.test.ts:223:13

The throw is scripts/tests/cli-npm-bin.test.ts:223, which surfaces a non-zero build-npm.ts exit. The abort is one layer below that, inside dnt's npm install.

Green reruns, same revision

No code changed between these runs.

Run	Command	Result
1	the nine-suite matrix above	35 passed | 1 failed — exit 1
2	deno task test scripts/tests/cli-npm-bin.test.ts alone	1 passed (4 steps) | 0 failed (2m12s) — exit 0
3	the same nine-suite matrix, repeated	36 passed (191 steps) | 0 failed (3m27s) — exit 0

That it passed alone and then passed again in the full matrix means the trigger is not deterministic in the matrix either.

Environment

Commit	9b13ce158aeafb573f46a7a684ec54b926f862a7 (branch agent/issue-822-git-plugin)
Deno	2.9.5 (stable, aarch64-apple-darwin), V8 15.0.245.2-rusty, TypeScript 6.0.3
Node	v26.5.1
Bun	1.3.14
npm	11.17.0
dnt	0.42.3
esbuild	0.28.2
OS	Darwin 27.0.0 arm64
CI run link	none — local only, not yet observed in CI

Why this is worth a issue rather than a retry

Exit 134 is SIGABRT, not an ordinary npm install failure: npm was killed rather than reporting a resolution or script error. The suite that hit it is one of the two that shell out to a full package build, and it failed only when sharing the machine with eight other suites, one of which (plugin-compiled.test.ts) also runs a heavyweight deno compile. Resource pressure during a concurrent native build is the obvious candidate, and if that is what it is, the same abort is available to CI on a smaller runner.

Two things would make it decidable rather than a guess:

• capture the npm install stderr from dnt rather than only its exit code, so an abort can be told apart from an OOM kill; and
• record whether the two build-heavy distribution suites can be kept off the same concurrency slot.

Not affected

The failure is entirely inside the generated npm package's install step. No product behavior, published file, manifest or lockfile is implicated, and the emitted bin ran correctly on every green run.