Summary
toolcraft@0.0.12 is unusable as published: importing anything from toolcraft/cli crashes at module load because a transitive @poe-code/process-runner is neither bundled in the tarball nor published to npm.
Repro
mkdir t && cd t && bun init -y
bun add toolcraft@0.0.12
echo 'import { runCLI } from "toolcraft/cli"; console.log(typeof runCLI);' > x.ts
bun x.ts
error: Cannot find module '@poe-code/process-runner' from
'.../node_modules/.bun/toolcraft@0.0.12/node_modules/toolcraft/node_modules/@poe-code/task-list/dist/backends/gh-issues-client.js'
Evidence
toolcraft@0.0.12's package.json lists @poe-code/task-list in bundleDependencies (good — it's in the tarball at package/node_modules/@poe-code/task-list/).
But the bundled @poe-code/task-list@0.0.1's own package.json declares:
"dependencies": {
"@poe-code/file-lock": "*",
"@poe-code/process-runner": "*",
"yaml": "*"
}
@poe-code/process-runner is:
- not in toolcraft's bundle (
ls package/node_modules/@poe-code/ → no process-runner)
- not published on npm —
curl -sI https://registry.npmjs.org/@poe-code/process-runner returns 404
It is imported eagerly at the top of @poe-code/task-list/dist/backends/gh-issues-client.js:
import { createHostRunner } from "@poe-code/process-runner";
…and that file is reachable from toolcraft's CLI entrypoint, so any import "toolcraft/cli" crashes.
The same *-version pattern means several other transitive deps (tiny-mcp-client, auth-store) only work because they happen to be bundled — process-runner slipped through.
Suggested fix
Any of:
- Add
@poe-code/process-runner to toolcraft's bundleDependencies so the tarball is self-contained.
- Publish
@poe-code/process-runner (and the other @poe-code/* workspace packages) to npm so installers can resolve them normally — and prefer real semver ranges over *.
- Make the
gh-issues-client backend in @poe-code/task-list lazy-load @poe-code/process-runner so it's only required when that backend is actually used.
For context: this blocked an attempt to migrate from poe-code/cmdkit (dropped from poe-code exports at 3.0.188) to standalone toolcraft. We're currently pinned at poe-code@3.0.187 because of this.
Summary
toolcraft@0.0.12is unusable as published: importing anything fromtoolcraft/clicrashes at module load because a transitive@poe-code/process-runneris neither bundled in the tarball nor published to npm.Repro
Evidence
toolcraft@0.0.12'spackage.jsonlists@poe-code/task-listinbundleDependencies(good — it's in the tarball atpackage/node_modules/@poe-code/task-list/).But the bundled
@poe-code/task-list@0.0.1's ownpackage.jsondeclares:@poe-code/process-runneris:ls package/node_modules/@poe-code/→ noprocess-runner)curl -sI https://registry.npmjs.org/@poe-code/process-runnerreturns 404It is imported eagerly at the top of
@poe-code/task-list/dist/backends/gh-issues-client.js:…and that file is reachable from toolcraft's CLI entrypoint, so any
import "toolcraft/cli"crashes.The same
*-version pattern means several other transitive deps (tiny-mcp-client,auth-store) only work because they happen to be bundled —process-runnerslipped through.Suggested fix
Any of:
@poe-code/process-runnerto toolcraft'sbundleDependenciesso the tarball is self-contained.@poe-code/process-runner(and the other@poe-code/*workspace packages) to npm so installers can resolve them normally — and prefer real semver ranges over*.gh-issues-clientbackend in@poe-code/task-listlazy-load@poe-code/process-runnerso it's only required when that backend is actually used.For context: this blocked an attempt to migrate from
poe-code/cmdkit(dropped frompoe-codeexports at 3.0.188) to standalonetoolcraft. We're currently pinned atpoe-code@3.0.187because of this.