How I ended up contributing five ways to shape an LLM's output

Yatin Davra — Fri, 03 Jul 2026 06:46:44 +0000

A few months back I was on a project that needed LLMs to return actual structured data, not prose I'd have to regex my way through. Simple enough in theory, except every provider wanted the shape described differently - Anthropic's SDK wanted a tool schema, OpenAI had its own response-format, Ollama was basically raw prompting and hoping. I was rewriting the same schema three times per feature and writing my own retry-on-invalid-output loop for anything that didn't guarantee output.

That's how I found ShapeCraft (@aviasole/shapecraft on npm). Define a schema once, hand it a model, get back validated data plus a guaranteeLevel telling you how much to trust it - "guaranteed" means something different on OpenAI's native schema enforcement than on Anthropic's prompt-and-validate approach than on Ollama's token-level grammar constraints.

It already supported Zod out of the box:

import { z } from "zod";
import { generate, openai } from "@aviasole/shapecraft";

const schema = z.object({ name: z.string(), score: z.number() });
const result = await generate(openai({ model: "gpt-4o-mini" }), schema, prompt);

That covered most of what I needed. But a few things in my actual project didn't fit "define a Zod schema," so instead of working around it, I opened some PRs.

Part of the data I was extracting already had a JSON Schema, generated by another tool upstream. Rewriting it as Zod types just to satisfy the library felt like busywork, so that became the first addition - pass the JSON Schema straight through:

const result = await generate(model, {
  jsonSchema: {
    type: "object",
    properties: { name: { type: "string" }, score: { type: "number" } },
    required: ["name", "score"],
  },
}, prompt);

Then I hit cases where I didn't need an object at all, just a string in a specific format. Wrapping that in an object schema felt like putting a hat on a hat, so next came a plain regex option:

const result = await generate(model, {
  pattern: /^\d{4}-\d{2}-\d{2}$/,
}, "What is today's date?");

After that, a rule that only made sense as logic, not a type - something like "required only if this other field equals X." Technically expressible as a schema, miserable to read. So I added a way to pass a validator function directly, plus a hint so the model still has something to aim for:

const result = await generate(model, {
  validate: (output) => typeof output === "object" && output !== null && "id" in output,
  hint: { type: "object", properties: { id: { type: "string" } } },
}, prompt);

The one that mattered most to me was separate from this project entirely. I also do Tally/TDL and GST integration work, and that world runs on XML - nested tags, required fields buried a few levels deep. None of the above helped there since the output isn't JSON-shaped at all. So the last addition was template-based XML: give it an example with typed placeholders, model fills them in.

const result = await generate(model, {
  xml: {
    template: `<book>
  <title>{string}</title>
  <author>{string}</author>
  <year>{number}</year>
</book>`,
    required: ["title", "author"],
  },
}, 'Extract: "Clean Code" by Robert C. Martin, 2008.');

This one took the most back-and-forth. Placeholders are deliberately limited to {string}, {number}, {boolean}, and a typo throws before the model is even called - that's a template bug, not something worth a retry.

The trickier part was literal text. Anything outside the {} is supposed to survive untouched, but it's best-effort by default - a model will occasionally "improve" fixed text that reads like an instruction, since nothing marks it as untouchable. There's an enforceLiterals: true flag that force-corrects every literal after the fact if you need that guaranteed. Or, often simpler, just leave the fixed value out of the template and splice it into result.data yourself afterward.

required also checks non-emptiness at any depth, so <items></items> still triggers a retry instead of counting as present. And arrays plus parse: true gets you back a parsed JS object instead of raw XML, with specific nodes coerced into arrays even with a single item.

One caveat worth knowing up front: XML generation is prompt-driven on every backend, no token-level grammar constraint like Ollama has for JSON. It leans on the model being capable, especially with deeply nested templates.

All five of these route through the same generate() call underneath - same retries, same guaranteeLevel, same error types (SchemaViolationError, MaxRetriesExceededError). Different doors into the same room, which is probably why it was easy to keep adding them.

Genuinely curious about a few things: if you've built template-based XML generation before, does enforceLiterals feel like the right approach, or is there a cleaner way without a re-serialize pass? Is there a schema style still missing that you've actually needed in production - YAML, something protobuf-shaped? And for the validator path, is a hint object enough context, or would you want more?

Repo's here: github.com/aviasoletechnologies/shapecraft. Package is @aviasole/shapecraft. I'm using it across a few different projects now, so I'll keep adding to it as I run into more edge cases.

How to Create Multi-Page TIFF Files in Node.js (Without ImageMagick)

Yatin Davra — Tue, 14 Apr 2026 13:11:31 +0000

If you've ever tried to create a multi-page TIFF in Node.js, you know the pain. Most solutions require ImageMagick as a system dependency, which is a headache in Docker, serverless environments, or CI pipelines. Others wrap native binaries with brittle child_processcalls.

I ran into this exact problem while building a document processing pipeline — I needed to merge multiple scanned images into a single multi-page TIFF programmatically, with no external system dependencies.

After digging through the options, I ended up writing a pure Node.js solution and published it as an npm package: multi-page-tiff.

The Problem

Multi-page TIFF files store multiple images as linked Image File Directories (IFDs) inside a single .tiff file. Creating one correctly means writing the TIFF binary structure yourself — most image libraries only handle reading, not writing multi-page TIFFs.

Common workarounds people try:

ImageMagick via child_process— works but requires ImageMagick installed, breaks in serverless
sharp — great library but doesn't support writing multi-page TIFFs
tiff-multipage — last published 3 years ago, minimal maintenance
tiff-to-png — converts TIFF to PNG, not the other way

The Solution

npm install multi-page-tiff

const { imagesToTiff, imagesToTiffBuffer } = require('multi-page-tiff');

const fs = require('fs');

const images = [
  fs.readFileSync('./page1.png'),
  fs.readFileSync('./page2.png'),
  fs.readFileSync('./page3.png'),
];

await imagesToTiff(images , 'output.tiff');

// Get a Buffer (useful for uploading, streaming, etc.)
const tiffBuffer = await imagesToTiffBuffer(images);
fs.writeFileSync('./output.tiff', tiffBuffer);

That's it. No native binaries, no system dependencies. Works on AWS Lambda, Vercel, Docker, Windows — anywhere Node.js runs.

Use Cases
Multi-page TIFFs are common in:

Fax systems — fax files are almost always multi-page TIFFs
Document scanning — scanners output multi-page TIFFs
Medical imaging — DICOM-adjacent workflows often use TIFF
Legal/archival — PDF alternatives for scanned documents
Insurance and banking — document submission pipelines

Why Not Just Use PDF?
TIFF is lossless, supports higher bit depths (16-bit, 32-bit), and is required in many enterprise, government, and medical workflows where PDF is not accepted. If your system specification says TIFF, there's usually no substitute.

Links

npm: npmjs.com/package/multi-page-tiff
GitHub: github.com/yatindavra/multi-page-tiff

If you've been fighting with multi-page TIFF generation in Node.js, give it a try and let me know in the comments if you run into any issues.
check my work at https://yatindavra.vercel.app

DEV Community: Yatin Davra

How I ended up contributing five ways to shape an LLM's output

How to Create Multi-Page TIFF Files in Node.js (Without ImageMagick)