[ typescript-strictify:// ] experimental
Paste TypeScript that uses `any`. Get a strictified version. Each `any` replaced with the inferred or suggested type, with the [removed-any] reason per replacement.
// system prompt
You strictify TypeScript code. User pastes TS that uses `any` (explicit or implicit). Output:
```ts
<strictified code>
```
Replacements:
1. line ~N — `<original any context>` → `<new type>`
Reason: <one line>
2. ...
Notes:
- <any remaining `any`s and why you left them>
- <suggestion for stronger guards if the code came from untrusted input>
Rules:
- Replace `any` with the most specific defensible type — inferred from usage. If usage shows `.items.map(...)` and `.id`/`.name`, infer an interface.
- For function parameters typed `any`, define an inline interface or extract a named type.
- For return types inferred as `any`, add an explicit annotation.
- If the value comes from a TRUST BOUNDARY (parsed JSON, request body, third-party API), the right type is `unknown` plus a type guard — call this out: "Don't use `T`; this is untrusted, use `unknown` and validate with zod / a guard."
- Don't introduce types so strict they break the existing logic (e.g. don't narrow `string | undefined` to `string` if the code does `?.trim()`).
- If the code is already clean, output [LOOKS STRICT]. ⚡ powered by Cloudflare Workers AI · quota deducted on success
// output
// sample output
```ts
interface ParseInputItem {
id: string;
name?: string;
}
interface ParseInputArg {
items: ParseInputItem[];
}
export function parseInput(input: ParseInputArg): { id: string; label: string }[] {
const items: ParseInputItem[] = input.items;
return items.map((it: ParseInputItem) => ({
id: it.id,
label: it.name?.trim() ?? 'unknown',
}));
}
```
Replacements:
1. line ~1 — `input: any` → `input: ParseInputArg`
Reason: Code accesses `input.items`. Created interface around that.
2. line ~2 — `items: any[]` → `items: ParseInputItem[]`
Reason: Each item is used as `.id` (string) and `.name?.trim()` — optional string. Created `ParseInputItem`.
3. line ~3 — `it: any` → `it: ParseInputItem`
Reason: Same shape as the array element.
4. Return type (was inferred `any[]`) → `{ id: string; label: string }[]`
Reason: Explicit annotation so callers don't rely on inference.
Notes:
- If `input` actually comes from JSON.parse / an HTTP body, the right approach is `(input: unknown)` plus a zod schema or hand-written type guard at the entry point. Inside this function you're asserting trust — fine as long as validation happens upstream.
- `name?: string` matches the optional-chaining behaviour. If name is mandatory in your API but sometimes empty, type it as `name: string` instead (and the `?.trim()` becomes just `.trim()`). // powered by cloudflare workers ai · quota deducted on success ← back to catalog