jochen
c46f9502ee
One repository, two modules (ADR 0069). `node-tools/` holds the runtime — its code, tests, package and the manifest of the module the controller composes a process for on every machine it is assigned to: a bundle of `src/main.js`, the interpreter as a package, a place for the node's credential, the loopback port the console declared, and leave to call every tool. Nothing about how it runs: which bundles to load, where the credential is and whose machine it is are the controller's to compose (WP2). The root module `mesh-tools` keeps the two images TypeScript bundles are compiled in and a module's own service may run in; it is no longer how tools reach a node. As node-tools, `serve` is also the console (ADR 0175 §6): the same process answers MCP on loopback for whoever is on the machine, through which the tools it serves can be called. A module's own runtime in a container keeps serving without a listener. The toolchain image now carries /app/runtime — a package.json saying the compiled files are ES modules and the production node_modules — for the builder to copy into every TypeScript bundle, so a bundle unpacked on a machine starts (ADR 0188 §5; the builder's side is the controller's). Proven here by compiling node-tools with the toolchain's exact flags and starting the result. The AMQP probe script is gone with the bus it probed.
24 lines
593 B
JSON
24 lines
593 B
JSON
{
|
|
"name": "@novox/mesh-tools",
|
|
"version": "0.1.0",
|
|
"description": "The Novox Mesh tool runtime \u2014 binds the mesh broker and serves the assigned modules' tools.",
|
|
"type": "module",
|
|
"bin": {
|
|
"mesh-tools": "./dist/main.js",
|
|
"mesh": "./dist/mesh.js"
|
|
},
|
|
"scripts": {
|
|
"build": "tsc",
|
|
"pretest": "tsc",
|
|
"test": "node --test --test-concurrency=1 --experimental-strip-types 'test/*.test.ts'"
|
|
},
|
|
"dependencies": {
|
|
"@novox/mesh-sdk": "^0.1.0",
|
|
"nats": "^2.29.0"
|
|
},
|
|
"devDependencies": {
|
|
"@types/node": "^22.20.1",
|
|
"typescript": "^5.9.3"
|
|
}
|
|
}
|