tsconfig.json
debt(d5/e3/b7/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list tsc and typescript itself as the tools. Misconfigured tsconfig issues (wrong module/moduleResolution pairing, missing strict, wrong target) are caught by the TypeScript compiler/language server but not by default linters — you need to actually run tsc or have a TypeScript-aware IDE plugin active. Some mismatches only surface at runtime or in specific tooling contexts, pushing slightly above d5 but not quite to code-review-only (d7).
Closest to 'simple parameterised fix' (e3). The quick_fix is essentially a set of top-level tsconfig.json property changes (target, module, strict, moduleResolution). Each individual fix is a one-liner, but addressing a misconfigured tsconfig holistically — especially module/moduleResolution mismatches that ripple into import paths — often requires adjusting several related settings and verifying the build still works, making it slightly more than a single-call swap.
Closest to 'strong gravitational pull' (b7). tsconfig.json applies to the entire web/cli codebase and is the foundation of TypeScript compilation. Every file in the project is compiled under its rules; strictness settings, module resolution, and target affect every module, every import, and every editor integration. A misconfigured tsconfig shapes all future TypeScript work — developers encounter its constraints on every change, and fixing it late can require touching many files (e.g., enabling strict after the fact).
Closest to 'serious trap' (t7). The misconception field explicitly states that developers believe tsconfig.json is optional and that defaults are safe — in reality, missing or misconfigured tsconfig causes module resolution failures, wrong JS output, and editor/CLI disagreements. The module+moduleResolution pairing is a well-known gotcha that contradicts how many developers expect configuration to work (each setting seeming independent but actually tightly coupled), and the 'optional with sane defaults' belief is directly contradicted by behavior.
Also Known As
TL;DR
Explanation
Key tsconfig options: strict (enable all strict checks), target (ES output version — ES2020+ for modern Node), module (CommonJS for Node, ESNext for bundlers), lib (DOM types for browser, ES2022 for Node), paths (import aliases), outDir (compiled output), sourceMap (debugging), and include/exclude (which files to compile). Project references enable monorepo compilation. The extends field enables shared base configs (tsconfig/bases packages).
Common Misconception
Why It Matters
Common Mistakes
- Not setting target appropriately — target: ES5 produces verbose output; ES2020+ is fine for modern Node and bundlers.
- Mismatching module and moduleResolution — module: CommonJS requires moduleResolution: node; module: ESNext requires bundler or node16.
- Not including source maps — debugging compiled TypeScript without source maps is painful.
- Over-broad include patterns — include: ['**/*'] compiles test files and config files into production output.
Code Examples
// Minimal tsconfig — many unsafe defaults:
{
"compilerOptions": {
"outDir": "./dist"
}
// No strict mode, no target, no module — compiler guesses
}// Production Node.js tsconfig:
{
"compilerOptions": {
"target": "ES2022",
"module": "NodeNext",
"moduleResolution": "NodeNext",
"lib": ["ES2022"],
"outDir": "./dist",
"rootDir": "./src",
"strict": true,
"sourceMap": true,
"declaration": true,
"skipLibCheck": true
},
"include": ["src/**/*"],
"exclude": ["node_modules", "dist"]
}