document-operations 1.1.75 → 1.1.76

package/dist/index.cjs

@@ -11,7 +11,7 @@ let document_outline_js = require("document-outline.js");
 /**
 * Builds a DocumentOperation whose input and output types are both inferred from real Zod schemas, so a call site never has to repeat `z.infer<typeof Schema>` itself. Use `defineOperationWithoutOutputSchema` instead for the rare operation whose original MCP tool registration declared no outputSchema at all.
 *
-* Deliberately returns the parameter object's own inferred literal type rather than an explicit `DocumentOperation<...>` return annotation. Zod 4's ZodType carries its own output type as one of three generic parameters (ZodType<Output, Input, Internals>), and TypeScript cannot prove, from inside this function body, that a generic `InputSchema extends z.ZodType` also extends `z.ZodType<z.infer<InputSchema>>` — the two-step indirection through an abstract type parameter defeats it even though it is true for every concrete schema. Letting the literal's own type flow out instead sidesteps that: a caller's own concrete schema (e.g. `ConvertDocumentInputSchema`) is trivially assignable to `DocumentOperation<In, Out>`'s `z.ZodType<In>` field wherever that supertype is actually needed (the registry array below, or a future MCP/REST/CLI adapter parameter), because widening a CONCRETE schema's output type to line up is a normal covariant check, not the same self-referential generic one.
+* Deliberately returns the parameter object's own inferred literal type rather than an explicit `DocumentOperation<...>` return annotation. Zod 4's ZodType carries its own output type as one of three generic parameters (`ZodType<Output, Input, Internals>`), and TypeScript cannot prove, from inside this function body, that a generic `InputSchema extends z.ZodType` also extends `z.ZodType<z.infer<InputSchema>>` — the two-step indirection through an abstract type parameter defeats it even though it is true for every concrete schema. Letting the literal's own type flow out instead sidesteps that: a caller's own concrete schema (e.g. `ConvertDocumentInputSchema`) is trivially assignable to `DocumentOperation<In, Out>`'s `z.ZodType<In>` field wherever that supertype is actually needed (the registry array below, or a future MCP/REST/CLI adapter parameter), because widening a CONCRETE schema's output type to line up is a normal covariant check, not the same self-referential generic one.
 */
 function defineOperation(operation) {
 	return operation;
@@ -218,7 +218,7 @@ const listDocumentConversionsOperation = defineOperation({
 	description: "Lists every (source, target) format pair convert_document actually supports, straight from documents.js's own DocumentConverter port — the definitive source of truth for what convert_document will and will not accept as a (source, targetFormat) combination.",
 	inputSchema: ListDocumentConversionsInputSchema,
 	outputSchema: ListDocumentConversionsOutputSchema,
-	run() {
+	async run() {
 		return Promise.resolve({ conversions: converter.conversions.map((conversion) => ({
 			source: conversion.source,
 			target: conversion.target
@@ -406,6 +406,9 @@ function appendMarkdownParagraphs(body, paragraphs) {
 		}
 	}
 }
+function assertNever(format) {
+	throw new Error(`createDocumentBytes: unhandled format ${String(format)}`);
+}
 function createDocumentBytes(format) {
 	switch (format) {
 		case "docx": return (0, documents_js.createDocx)().toBytes();
@@ -417,6 +420,7 @@ function createDocumentBytes(format) {
 		case "pdf": return (0, documents_js.createPdf)().toBytes();
 		case "markdown": return (0, documents_js.encodeMarkdownText)((0, documents_js.createMarkdownEditor)().toMarkdownText());
 	}
+	return assertNever(format);
 }
 const ResolvedDocumentOutputSchema$2 = zod.z.union([zod.z.object({
 	path: zod.z.string(),

package/dist/index.d.cts

@@ -22,7 +22,7 @@ interface DocumentOperation<In = unknown, Out = unknown> {
 /**
  * Builds a DocumentOperation whose input and output types are both inferred from real Zod schemas, so a call site never has to repeat `z.infer<typeof Schema>` itself. Use `defineOperationWithoutOutputSchema` instead for the rare operation whose original MCP tool registration declared no outputSchema at all.
  *
- * Deliberately returns the parameter object's own inferred literal type rather than an explicit `DocumentOperation<...>` return annotation. Zod 4's ZodType carries its own output type as one of three generic parameters (ZodType<Output, Input, Internals>), and TypeScript cannot prove, from inside this function body, that a generic `InputSchema extends z.ZodType` also extends `z.ZodType<z.infer<InputSchema>>` — the two-step indirection through an abstract type parameter defeats it even though it is true for every concrete schema. Letting the literal's own type flow out instead sidesteps that: a caller's own concrete schema (e.g. `ConvertDocumentInputSchema`) is trivially assignable to `DocumentOperation<In, Out>`'s `z.ZodType<In>` field wherever that supertype is actually needed (the registry array below, or a future MCP/REST/CLI adapter parameter), because widening a CONCRETE schema's output type to line up is a normal covariant check, not the same self-referential generic one.
+ * Deliberately returns the parameter object's own inferred literal type rather than an explicit `DocumentOperation<...>` return annotation. Zod 4's ZodType carries its own output type as one of three generic parameters (`ZodType<Output, Input, Internals>`), and TypeScript cannot prove, from inside this function body, that a generic `InputSchema extends z.ZodType` also extends `z.ZodType<z.infer<InputSchema>>` — the two-step indirection through an abstract type parameter defeats it even though it is true for every concrete schema. Letting the literal's own type flow out instead sidesteps that: a caller's own concrete schema (e.g. `ConvertDocumentInputSchema`) is trivially assignable to `DocumentOperation<In, Out>`'s `z.ZodType<In>` field wherever that supertype is actually needed (the registry array below, or a future MCP/REST/CLI adapter parameter), because widening a CONCRETE schema's output type to line up is a normal covariant check, not the same self-referential generic one.
  */
 declare function defineOperation<InputSchema extends z.ZodType, OutputSchema extends z.ZodType>(operation: {
   readonly name: string;
@@ -2041,7 +2041,7 @@ declare const pdfInspectOperation: {
         font: {
           family: string;
           weight: "bold" | "normal";
-          style: "italic" | "normal";
+          style: "normal" | "italic";
         };
         sizePt: number;
         color: {

package/dist/index.d.ts

@@ -22,7 +22,7 @@ interface DocumentOperation<In = unknown, Out = unknown> {
 /**
  * Builds a DocumentOperation whose input and output types are both inferred from real Zod schemas, so a call site never has to repeat `z.infer<typeof Schema>` itself. Use `defineOperationWithoutOutputSchema` instead for the rare operation whose original MCP tool registration declared no outputSchema at all.
  *
- * Deliberately returns the parameter object's own inferred literal type rather than an explicit `DocumentOperation<...>` return annotation. Zod 4's ZodType carries its own output type as one of three generic parameters (ZodType<Output, Input, Internals>), and TypeScript cannot prove, from inside this function body, that a generic `InputSchema extends z.ZodType` also extends `z.ZodType<z.infer<InputSchema>>` — the two-step indirection through an abstract type parameter defeats it even though it is true for every concrete schema. Letting the literal's own type flow out instead sidesteps that: a caller's own concrete schema (e.g. `ConvertDocumentInputSchema`) is trivially assignable to `DocumentOperation<In, Out>`'s `z.ZodType<In>` field wherever that supertype is actually needed (the registry array below, or a future MCP/REST/CLI adapter parameter), because widening a CONCRETE schema's output type to line up is a normal covariant check, not the same self-referential generic one.
+ * Deliberately returns the parameter object's own inferred literal type rather than an explicit `DocumentOperation<...>` return annotation. Zod 4's ZodType carries its own output type as one of three generic parameters (`ZodType<Output, Input, Internals>`), and TypeScript cannot prove, from inside this function body, that a generic `InputSchema extends z.ZodType` also extends `z.ZodType<z.infer<InputSchema>>` — the two-step indirection through an abstract type parameter defeats it even though it is true for every concrete schema. Letting the literal's own type flow out instead sidesteps that: a caller's own concrete schema (e.g. `ConvertDocumentInputSchema`) is trivially assignable to `DocumentOperation<In, Out>`'s `z.ZodType<In>` field wherever that supertype is actually needed (the registry array below, or a future MCP/REST/CLI adapter parameter), because widening a CONCRETE schema's output type to line up is a normal covariant check, not the same self-referential generic one.
  */
 declare function defineOperation<InputSchema extends z.ZodType, OutputSchema extends z.ZodType>(operation: {
   readonly name: string;
@@ -2041,7 +2041,7 @@ declare const pdfInspectOperation: {
         font: {
           family: string;
           weight: "bold" | "normal";
-          style: "italic" | "normal";
+          style: "normal" | "italic";
         };
         sizePt: number;
         color: {

package/dist/index.js

@@ -10,7 +10,7 @@ import { buildOutline, isOutlineNode, outlineLeafText } from "document-outline.j
 /**
 * Builds a DocumentOperation whose input and output types are both inferred from real Zod schemas, so a call site never has to repeat `z.infer<typeof Schema>` itself. Use `defineOperationWithoutOutputSchema` instead for the rare operation whose original MCP tool registration declared no outputSchema at all.
 *
-* Deliberately returns the parameter object's own inferred literal type rather than an explicit `DocumentOperation<...>` return annotation. Zod 4's ZodType carries its own output type as one of three generic parameters (ZodType<Output, Input, Internals>), and TypeScript cannot prove, from inside this function body, that a generic `InputSchema extends z.ZodType` also extends `z.ZodType<z.infer<InputSchema>>` — the two-step indirection through an abstract type parameter defeats it even though it is true for every concrete schema. Letting the literal's own type flow out instead sidesteps that: a caller's own concrete schema (e.g. `ConvertDocumentInputSchema`) is trivially assignable to `DocumentOperation<In, Out>`'s `z.ZodType<In>` field wherever that supertype is actually needed (the registry array below, or a future MCP/REST/CLI adapter parameter), because widening a CONCRETE schema's output type to line up is a normal covariant check, not the same self-referential generic one.
+* Deliberately returns the parameter object's own inferred literal type rather than an explicit `DocumentOperation<...>` return annotation. Zod 4's ZodType carries its own output type as one of three generic parameters (`ZodType<Output, Input, Internals>`), and TypeScript cannot prove, from inside this function body, that a generic `InputSchema extends z.ZodType` also extends `z.ZodType<z.infer<InputSchema>>` — the two-step indirection through an abstract type parameter defeats it even though it is true for every concrete schema. Letting the literal's own type flow out instead sidesteps that: a caller's own concrete schema (e.g. `ConvertDocumentInputSchema`) is trivially assignable to `DocumentOperation<In, Out>`'s `z.ZodType<In>` field wherever that supertype is actually needed (the registry array below, or a future MCP/REST/CLI adapter parameter), because widening a CONCRETE schema's output type to line up is a normal covariant check, not the same self-referential generic one.
 */
 function defineOperation(operation) {
 	return operation;
@@ -217,7 +217,7 @@ const listDocumentConversionsOperation = defineOperation({
 	description: "Lists every (source, target) format pair convert_document actually supports, straight from documents.js's own DocumentConverter port — the definitive source of truth for what convert_document will and will not accept as a (source, targetFormat) combination.",
 	inputSchema: ListDocumentConversionsInputSchema,
 	outputSchema: ListDocumentConversionsOutputSchema,
-	run() {
+	async run() {
 		return Promise.resolve({ conversions: converter.conversions.map((conversion) => ({
 			source: conversion.source,
 			target: conversion.target
@@ -405,6 +405,9 @@ function appendMarkdownParagraphs(body, paragraphs) {
 		}
 	}
 }
+function assertNever(format) {
+	throw new Error(`createDocumentBytes: unhandled format ${String(format)}`);
+}
 function createDocumentBytes(format) {
 	switch (format) {
 		case "docx": return createDocx().toBytes();
@@ -416,6 +419,7 @@ function createDocumentBytes(format) {
 		case "pdf": return createPdf().toBytes();
 		case "markdown": return encodeMarkdownText(createMarkdownEditor().toMarkdownText());
 	}
+	return assertNever(format);
 }
 const ResolvedDocumentOutputSchema$2 = z.union([z.object({
 	path: z.string(),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "document-operations",
-  "version": "1.1.75",
+  "version": "1.1.76",
   "description": "The canonical set of document-conversion, editing, inspection, and .odb operations documents.js exposes — one Zod input/output schema and one transport-agnostic run() function per operation, shared by document-mcp, document-cli, and a REST API server rather than each defining its own copy.",
   "type": "module",
   "repository": {
@@ -82,10 +82,10 @@
   "license": "MIT",
   "packageManager": "pnpm@12.4.1+sha512.2e81e399d73fe8390dab25e06aa788ab7a5908248d2f5a370f82b481147a6a7a367bf8048f9a6fdb6460f21a66f0542dedb8b94ca2c8723596741920b1656d4c",
   "dependencies": {
-    "document-compute.js": "1.6.23",
+    "document-compute.js": "1.6.24",
     "document-outline.js": "3.10.15",
     "document-schema.js": "7.15.0",
-    "documents.js": "14.4.14",
+    "documents.js": "14.4.15",
     "zod": "4.4.3"
   },
   "devDependencies": {