mthds 0.13.1 → 0.14.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,20 @@
1
+ /**
2
+ * Client-safe error taxonomy — the SDK's exception classes, exported from a
3
+ * module whose graph has NO Node-only dependencies, so it can be imported from a
4
+ * browser/client bundle. Published as the `mthds/errors` subpath.
5
+ *
6
+ * Why a separate entry: the top-level barrel (`mthds`) statically re-exports
7
+ * `MthdsApiClient`, whose graph pulls `config/` → `node:fs` at module load. A
8
+ * client bundler (e.g. Next.js / Turbopack) cannot externalize `node:fs` and
9
+ * fails the build — even when the consumer only wanted an error class for an
10
+ * `instanceof` check. Code that needs to classify an error on the client (e.g.
11
+ * `err instanceof ApiResponseError`) imports the classes from here instead of
12
+ * the top-level barrel.
13
+ *
14
+ * These are the same error classes the top-level barrel exports; the two cannot
15
+ * drift because both re-export from the same source modules. The graph here is
16
+ * `protocol/exceptions` (zero imports) + `runners/api/exceptions` (whose only
17
+ * runtime import is `protocol/exceptions`), so it stays free of Node built-ins.
18
+ */
19
+ export { PipelineRequestError } from "./protocol/exceptions.js";
20
+ export { ApiResponseError, ApiUnreachableError, ClientAuthenticationError, PipelineExecuteTimeoutError, RunStillRunningError, } from "./runners/api/exceptions.js";
package/dist/errors.js ADDED
@@ -0,0 +1,23 @@
1
+ /**
2
+ * Client-safe error taxonomy — the SDK's exception classes, exported from a
3
+ * module whose graph has NO Node-only dependencies, so it can be imported from a
4
+ * browser/client bundle. Published as the `mthds/errors` subpath.
5
+ *
6
+ * Why a separate entry: the top-level barrel (`mthds`) statically re-exports
7
+ * `MthdsApiClient`, whose graph pulls `config/` → `node:fs` at module load. A
8
+ * client bundler (e.g. Next.js / Turbopack) cannot externalize `node:fs` and
9
+ * fails the build — even when the consumer only wanted an error class for an
10
+ * `instanceof` check. Code that needs to classify an error on the client (e.g.
11
+ * `err instanceof ApiResponseError`) imports the classes from here instead of
12
+ * the top-level barrel.
13
+ *
14
+ * These are the same error classes the top-level barrel exports; the two cannot
15
+ * drift because both re-export from the same source modules. The graph here is
16
+ * `protocol/exceptions` (zero imports) + `runners/api/exceptions` (whose only
17
+ * runtime import is `protocol/exceptions`), so it stays free of Node built-ins.
18
+ */
19
+ // ── Protocol-base error (pure protocol layer — no Node deps) ──
20
+ export { PipelineRequestError } from "./protocol/exceptions.js";
21
+ // ── API-runner errors (runners/api/exceptions — graph is protocol-only) ──
22
+ export { ApiResponseError, ApiUnreachableError, ClientAuthenticationError, PipelineExecuteTimeoutError, RunStillRunningError, } from "./runners/api/exceptions.js";
23
+ //# sourceMappingURL=errors.js.map
@@ -0,0 +1 @@
1
+ {"version":3,"file":"errors.js","sourceRoot":"","sources":["../src/errors.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAEH,iEAAiE;AACjE,OAAO,EAAE,oBAAoB,EAAE,MAAM,0BAA0B,CAAC;AAEhE,4EAA4E;AAC5E,OAAO,EACL,gBAAgB,EAChB,mBAAmB,EACnB,yBAAyB,EACzB,2BAA2B,EAC3B,oBAAoB,GACrB,MAAM,6BAA6B,CAAC"}
@@ -9,7 +9,7 @@ export declare function isUvInstalled(): boolean;
9
9
  export declare function installUv(): void;
10
10
  /**
11
11
  * Ensure pipelex is installed, using uv tool install with spinner feedback.
12
- * Used by interactive CLI commands (mthds install, mthds setup, etc.).
12
+ * Used by interactive CLI commands (mthds install, mthds runner setup, etc.).
13
13
  */
14
14
  export declare function ensureRuntime(): Promise<void>;
15
15
  /**
@@ -51,7 +51,7 @@ export function installUv() {
51
51
  // ── Async install (interactive, with spinner) ────────────────────────
52
52
  /**
53
53
  * Ensure pipelex is installed, using uv tool install with spinner feedback.
54
- * Used by interactive CLI commands (mthds install, mthds setup, etc.).
54
+ * Used by interactive CLI commands (mthds install, mthds runner setup, etc.).
55
55
  */
56
56
  export async function ensureRuntime() {
57
57
  if (!isPipelexInstalled()) {
@@ -9,7 +9,8 @@ import type { ModelCategory, ModelDeck, RunResultExecute, RunResultStart, Valida
9
9
  * `execute`, `start`, `validate`, `models`, `version`. A runner is just a
10
10
  * runner: it executes and validates methods, and reports its model deck and
11
11
  * version. Run polling is NOT part of the protocol — it is a hosted-API
12
- * extension carried by `MthdsApiClient` and the `Runner` interface only.
12
+ * extension that now lives in the Pipelex runtime SDK (`@pipelex/sdk` /
13
+ * `pipelex-agent`), not in this package.
13
14
  *
14
15
  * Generic in `PipeOutputT` (mirroring python's `Generic[PipeOutputT]`): the
15
16
  * generic is the mechanism that keeps `protocol/` pure — `execute` returns
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "mthds",
3
- "version": "0.13.1",
3
+ "version": "0.14.0",
4
4
  "description": "CLI and SDK for MTHDS — the open standard for executable AI methods. Install, execute, and manage methods.",
5
5
  "license": "MIT",
6
6
  "repository": {
@@ -18,6 +18,10 @@
18
18
  "./protocol": {
19
19
  "import": "./dist/protocol/index.js",
20
20
  "types": "./dist/protocol/index.d.ts"
21
+ },
22
+ "./errors": {
23
+ "import": "./dist/errors.js",
24
+ "types": "./dist/errors.d.ts"
21
25
  }
22
26
  },
23
27
  "bin": {