What this prompt does
This prompt makes the model set up the strictest sensible TypeScript configuration for a new project and, crucially, explain every non-obvious choice rather than dumping config you can't reason about. It produces a tight tsconfig.json, a typed ESLint flat config, and the npm scripts to run them, so the compiler and linter catch bugs before code review does. The point is to pay the strictness tax on day one instead of chasing undefined-at-runtime bugs in production later.
The [project_type] variable shapes the config — a library, an app, or a monorepo needs different module and build settings. [framework] (the framework or runtime) further tunes things like JSX and module resolution, and [package_manager] decides how the typecheck, lint, and lint:fix scripts are wired. The tsconfig turns on strict, noUncheckedIndexedAccess, exactOptionalPropertyTypes, noImplicitOverride, isolatedModules, and verbatimModuleSyntax, and the prompt explains what each one actually catches so you adopt them deliberately rather than cargo-culting a settings file.
When to use it
- Starting a fresh TypeScript project and wanting maximum compiler safety from commit one.
- Standardising strictness and lint rules across multiple repos or a team.
- Setting up a library plus app monorepo where module settings need to be correct.
- Adding a typed ESLint flat config with clean Prettier handoff and sensible unused-var rules.
- Ratcheting strict rules onto an existing codebase without drowning in errors at once.
- Justifying each strict flag to teammates who push back on the added friction.
Example output
You get both config files in full — the tsconfig.json and the ESLint flat config — followed by a short table of Rule, What it prevents, and Cost. The ESLint side uses typescript-eslint strict-type-checked, import ordering, unused-var detection that allows underscore-prefixed args, and a clean Prettier handoff so the linter and formatter don't fight. Scripts for typecheck, lint, and lint:fix are wired for [package_manager], and a migration note explains incremental ratcheting for legacy code. It's a complete drop-in setup with the reasoning attached, not opaque boilerplate.
Pro tips
- Set
[project_type]precisely — a library, an app, and a monorepo each need differenttsconfigmodule and output settings, and guessing produces subtle build issues. - Match
[package_manager]to what you actually use so the generated scripts run without rewriting them. - For existing code, lean on the migration note: enable rules incrementally rather than turning everything on and facing thousands of errors.
- Read the Rule/Cost table before accepting every flag; some, like
exactOptionalPropertyTypes, change real ergonomics and are worth a conscious decision. - Confirm
[framework]so module resolution and any JSX settings match your runtime instead of a generic default. - Keep the Prettier handoff clean — let ESLint handle code-quality rules and Prettier handle formatting, so they don't fight.
