El fichero tsconfig.json controla qué comprueba TypeScript, a qué versión de JavaScript compila y cómo resuelve los módulos. Con decenas de opciones disponibles, es fácil perderse. Esta guía cubre las que realmente importan, qué activa strict, y ofrece configuraciones base listas para proyectos Node.js, React y librerías npm.
strict y todo lo que activa
"strict": true es la opción más importante. Activa un conjunto de comprobaciones que TypeScript no habilita por defecto para mantener la retrocompatibilidad, pero que hacen el código mucho más seguro:
- noImplicitAny: error cuando TypeScript infiere
anyimplícitamente (parámetros sin tipo, etc.). - strictNullChecks:
nullyundefinedno son asignables a otros tipos sin comprobación. - strictFunctionTypes: comprobación más estricta de la compatibilidad entre tipos de función.
- strictBindCallApply: tipos correctos para
bind,callyapply. - strictPropertyInitialization: error si una propiedad de clase no se inicializa en el constructor.
- noImplicitThis: error cuando
thistiene tipoanyimplícito. - alwaysStrict: emite
"use strict"en todos los ficheros.
target y module
target define a qué versión de JavaScript compila TypeScript. En 2026 el valor más habitual en proyectos nuevos es ES2022 o ESNext, que preserva características modernas como async/await nativo, clases con campos privados (#) y top-level await.
module controla qué formato de módulos emite TypeScript. Para proyectos Node.js modernos: NodeNext. Para proyectos con bundler (Vite, webpack): ESNext.
moduleResolution y esModuleInterop
moduleResolution determina el algoritmo de resolución de imports. Las opciones relevantes son bundler (para proyectos con Vite/webpack), NodeNext (para Node.js con ESM) y node (legacy, para compatibilidad).
esModuleInterop: true permite importar módulos CommonJS con la sintaxis de import por defecto: import fs from "fs" en lugar de import * as fs from "fs". Casi siempre debe estar activado en proyectos modernos.
skipLibCheck
skipLibCheck: true omite la comprobación de tipos en los ficheros .d.ts de las librerías. Es útil para evitar errores en tipos de terceros que no están perfectamente escritos. En proyectos grandes es prácticamente indispensable para mantener los tiempos de compilación razonables.
Configuraciones base listas para usar
Para un proyecto Node.js con ESM:
{
"compilerOptions": {
"target": "ES2022",
"module": "NodeNext",
"moduleResolution": "NodeNext",
"outDir": "dist",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"declaration": true,
"declarationMap": true,
"sourceMap": true
},
"include": ["src"],
"exclude": ["node_modules", "dist"]
}
Para un proyecto React con Vite:
{
"compilerOptions": {
"target": "ES2020",
"lib": ["ES2020", "DOM", "DOM.Iterable"],
"module": "ESNext",
"moduleResolution": "bundler",
"jsx": "react-jsx",
"strict": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"noFallthroughCasesInSwitch": true,
"skipLibCheck": true
}
}
Para una librería npm que publica tipos:
{
"compilerOptions": {
"target": "ES2020",
"module": "ESNext",
"moduleResolution": "bundler",
"declaration": true,
"declarationDir": "dist/types",
"outDir": "dist",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true
}
}
El punto de partida recomendado es strict: true desde el inicio. Activarlo en un proyecto ya existente puede ser doloroso: genera decenas de errores de tipos que había que haber capturado antes. La deuda técnica de no usarlo crece con el proyecto.
Imagen: Pexels / Myburgh Roux
