@cloudflare/codemode: zod-to-ts pulls in typescript, breaks Workers deploy

[mattzcarey]

Problem

When installing @cloudflare/codemode from npm (v0.1.2) and deploying to Cloudflare Workers, the deploy fails with:

Uncaught ReferenceError: __filename is not defined
  at typescript.js:8487 in isFileSystemCaseSensitive
  ...
  at zod-to-ts/dist/index.js:1:34

Root cause

@cloudflare/codemode depends on zod-to-ts@^2.0.0, which has typescript as a peer dependency. The zod-to-ts import is in types-CpkEgXwN.js, which is eagerly imported by both ai.js and index.js:

// dist/ai.js
import { n as sanitizeToolName, t as generateTypes } from "./types-CpkEgXwN.js";

// dist/types-CpkEgXwN.js
import { createAuxiliaryTypeStore, createTypeAlias, printNode, zodToTs } from "zod-to-ts";

typescript is a CJS package that uses __filename at the top level, which doesn't exist in the Workers runtime. This causes the deploy validation to fail with error code 10021.

Workaround

Using a file: link to the local monorepo package works because the monorepo build/bundling handles tree-shaking differently. The published npm package does not.

Suggested fix

Either:

1. Lazy-import zod-to-ts so it's only loaded when generateTypes() is actually called (not at module load time)
2. Split the chunks so that ai.js (which provides createCodeTool) doesn't import the types module unless generateTypes is explicitly used
3. Replace zod-to-ts with a lighter schema-to-TS converter that doesn't depend on the full typescript package

Option 1 is probably the smallest change — a dynamic import("zod-to-ts") inside generateTypes() would prevent typescript from being eagerly loaded.

[nathanschram]

Yeah, your analysis is spot on here. The eager import chain from types.ts -> zod-to-ts -> typescript is the problem, and since the shared chunk (types-CpkEgXwN.js) gets pulled into both ai.js and index.js, there's no way to avoid it as a consumer.

This is actually the same underlying issue as #623 from back in November - the define: { "__filename": "'index.ts'" } workaround from that thread works as a stopgap, but it's not a real fix.

Your PR #1074 looks like the right approach - removing zod-to-ts entirely and going through JSON Schema avoids the typescript dependency altogether. Much cleaner than lazy-loading it.