TechnicalCollectible prompt

Fix TypeScript errors that fail your build, properly

Clear build-breaking type errors by fixing the real mismatch, not with ts-ignore, any or skipped checks.

CursorClaude CodeCodex

Curated by Nvoka

Nvoka wordmark logo
Nvoka wordmark logoTechnical

Fix TypeScript errors that fail your build, properly

Act as a senior TypeScript engineer. My {{tech_stack}} build fails with type errors. Here's the build output: {{error_message}} Work like this: 1. Reproduce: run the same typecheck and build command the host runs, locally, and confirm the same errors. If it fails only on the host, compare TypeScript and Node versions, and check whether the host runs a stricter check than the dev server. Many dev servers skip type checking entirely. 2. Triage: group errors by root cause, not by file. One wrong type often causes dozens of errors downstream, so fix the first error in each chain and rerun. 3. Common causes for this symptom: - Values that can be null or undefined used as if always present, such as query results or route params - Database or API types out of date after a schema change; regenerate them rather than hand-editing - A package upgrade that changed its types, or two versions of the same types installed - Implicit any from untyped parameters and event handlers - Wrong imports: a type imported as a value, default versus named exports, or path aliases the build doesn't know - Component props changed in one place but not at the call sites 4. Fix each at the source: narrow with checks, handle the empty and error cases, type the boundaries (API responses, form data) with a schema validator, and update the callers. Not allowed: ts-ignore or ts-expect-error without a written reason, casting to any or unknown to silence an error, non-null assertions on data that really can be missing, or turning off strict mode or the build's type check. Finish with the root causes in plain words, the files changed, and a CI step that runs the typecheck on every push.
Technicalnvoka.com/library/nvoka-fix-typescript-errors-that-fail-your-buildScan to open
Technical

Fix TypeScript errors that fail your build, properly

Clear build-breaking type errors by fixing the real mismatch, not with ts-ignore, any or skipped checks.

Nvoka logo

Curated by Nvoka

CursorClaude CodeCodexGitHub Copilot
Add to my library

Make it yours

Fill in the blanks and change any word. Only your copy changes, never the card.

Fill in the blanks

0 of 2 filled

Your prompt

Act as a senior TypeScript engineer. My {{tech_stack}} build fails with type errors. Here's the build output: {{error_message}} Work like this: 1. Reproduce: run the same typecheck and build command the host runs, locally, and confirm the same errors. If it fails only on the host, compare TypeScript and Node versions, and check whether the host runs a stricter check than the dev server. Many dev servers skip type checking entirely. 2. Triage: group errors by root cause, not by file. One wrong type often causes dozens of errors downstream, so fix the first error in each chain and rerun. 3. Common causes for this symptom: - Values that can be null or undefined used as if always present, such as query results or route params - Database or API types out of date after a schema change; regenerate them rather than hand-editing - A package upgrade that changed its types, or two versions of the same types installed - Implicit any from untyped parameters and event handlers - Wrong imports: a type imported as a value, default versus named exports, or path aliases the build doesn't know - Component props changed in one place but not at the call sites 4. Fix each at the source: narrow with checks, handle the empty and error cases, type the boundaries (API responses, form data) with a schema validator, and update the callers. Not allowed: ts-ignore or ts-expect-error without a written reason, casting to any or unknown to silence an error, non-null assertions on data that really can be missing, or turning off strict mode or the build's type check. Finish with the root causes in plain words, the files changed, and a CI step that runs the typecheck on every push.
See all