Modo Estricto de TypeScript y Verificaciones del Compilador

Habilita las opciones estrictas del compilador de TypeScript para detectar más errores en tiempo de compilación y complementar ESLint con seguridad de tipos.

Receta

Tarjeta de referencia rápida — lista para copiar y pegar.

# Verifica tipos sin emitir archivos
npx tsc --noEmit
 
# Verifica tipos en modo watch durante desarrollo
npx tsc --noEmit --watch
 
# Agregue a package.json
# "type-check": "tsc --noEmit"

Cuándo usarlo: Todo proyecto TypeScript debe habilitar strict mode. La pregunta no es si, sino qué tan rápido puedes activar cada opción.

Ejemplo de Trabajo

// tsconfig.json
{
  "compilerOptions": {
    // --- Strict mode (flag sombrilla) ---
    "strict": true,
    // "strict" habilita todas estas:
    //   "strictNullChecks": true,
    //   "strictFunctionTypes": true,
    //   "strictBindCallApply": true,
    //   "strictPropertyInitialization": true,
    //   "noImplicitAny": true,
    //   "noImplicitThis": true,
    //   "alwaysStrict": true,
    //   "useUnknownInCatchVariables": true,
 
    // --- Verificaciones estrictas adicionales (no en "strict") ---
    "noUncheckedIndexedAccess": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitOverride": true,
    "exactOptionalPropertyTypes": true,
 
    // --- Configuración de módulos e imports ---
    "verbatimModuleSyntax": true,
    "moduleResolution": "bundler",
    "module": "esnext",
    "target": "es2017",
 
    // --- Alias de rutas ---
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    },
 
    // --- Salida ---
    "noEmit": true,
    "jsx": "preserve",
    "incremental": true,
 
    // --- Interoperabilidad ---
    "esModuleInterop": true,
    "allowJs": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "skipLibCheck": true
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"],
  "exclude": ["node_modules"]
}

Lo que esto demuestra:

• Modo strict completo habilitado como línea base
• Verificaciones adicionales más allá de strict para máxima seguridad
• verbatimModuleSyntax para imports de solo tipo explícitos
• noUncheckedIndexedAccess para forzar verificaciones nulas en acceso a arrays y objetos
• Configuración compatible con Next.js (noEmit, jsx: "preserve", moduleResolution: "bundler")

Análisis Profundo

Cómo Funciona

• "strict": true es una flag sombrilla que habilita ocho verificaciones estrictas individuales
• Flags adicionales como noUncheckedIndexedAccess no están incluidas en strict y deben habilitarse por separado
• TypeScript verifica en tiempo de compilación y detecta una clase completa de errores que ESLint no puede (desajustes de tipo, propiedades faltantes, firmas de función incorrectas)
• tsc --noEmit ejecuta el verificador de tipos sin producir archivos de salida (Next.js maneja la compilación vía SWC)

Variaciones

Lo que cada opción estricta detecta:

Habilitación del modo estricto incrementalmente:

// Paso 1: Comienza con strict false pero habilita opciones una por una
{
  "compilerOptions": {
    "strict": false,
    "strictNullChecks": true,    // Habilita primero — máximo impacto
    "noImplicitAny": true         // Habilita segundo
    // Agrega más conforme corriges errores
  }
}

# Cuenta errores restantes para rastrear progreso
npx tsc --noEmit 2>&1 | grep "error TS" | wc -l

Reglas typescript-eslint que complementan tsconfig:

// Estas reglas ESLint detectan patrones que tsc no marca:
{
  rules: {
    "@typescript-eslint/no-floating-promises": "error",    // Promesas no manejadas
    "@typescript-eslint/no-misused-promises": "error",     // Promesas en contextos incorrectos
    "@typescript-eslint/await-thenable": "error",           // await en no-Promise
    "@typescript-eslint/no-unnecessary-condition": "warn",  // Condiciones siempre-verdaderas
    "@typescript-eslint/prefer-nullish-coalescing": "warn", // || vs ??
    "@typescript-eslint/strict-boolean-expressions": "warn", // Verificaciones verídicas en no-booleans
  },
}

Nota: Estas reglas requieren que parserOptions.project esté configurado para linting consciente de tipos.

Notas de TypeScript

// verbatimModuleSyntax fuerza imports de tipo explícitos:
import type { User } from "@/types";        // Solo tipo — borrado en runtime
import { fetchUser } from "@/lib/api";       // Valor — mantenido en runtime
 
// noUncheckedIndexedAccess en acción:
const items = ["a", "b", "c"];
const first = items[0]; // Tipo: string | undefined (no string)
if (first) {
  console.log(first.toUpperCase()); // Seguro — estrechado a string
}
 
// Sin noUncheckedIndexedAccess:
const risky = items[0]; // Tipo: string (miente — podría ser undefined)
risky.toUpperCase(); // Crash en runtime si el array está vacío

Trampa y Errores Comunes

Cosas que te atraparan. Cada trampa incluye qué sale mal, por qué sucede, y la solución.

• strictNullChecks crea muchos errores — Habilitar esto en un proyecto grande existente puede producir cientos o miles de errores. Solución: Habilita incrementalmente. Usa // @ts-expect-error temporalmente para código seguro conocido y corrige errores archivo por archivo.

• noUncheckedIndexedAccess es ruidoso — Cada array[i] y obj[key] se convierte en T | undefined, requiriendo verificaciones nulas incluso cuando sabes que el valor existe. Solución: Usa aserción no-nula (items[0]!) esporádicamente donde has verificado que el valor existe, o usa .at(0) con una verificación nula.

• exactOptionalPropertyTypes rompe patrones comunes — Ya no puedes escribir { name?: string } y asignar undefined explícitamente. Solución: Solo habilita esto si tu código distingue entre propiedades "faltantes" y "explícitamente undefined". La mayoría de proyectos saltan esta opción.

• Las reglas ESLint conscientes de tipos son lentas — Reglas como no-floating-promises requieren información de tipo completa, haciendo ESLint 2 a 5 veces más lento. Solución: Solo habilita reglas conscientes de tipos si el tradeoff vale la pena. Considera ejecutarlas solo en CI, no en el editor.

• verbatimModuleSyntax y CommonJS — Esta opción no funciona bien con módulos CommonJS. Solución: Solo habilítala en proyectos usando módulos ES (que incluye todos los proyectos Next.js App Router).

Alternativas

Otras formas de resolver el mismo problema — y cuándo cada una es la mejor opción.

Preguntas Frecuentes

const items = ["a", "b", "c"];
const first = items[0]; // Tipo: string | undefined (no string)
if (first) {
  console.log(first.toUpperCase()); // Seguro después de estrechar
}

npx tsc --noEmit 2>&1 | grep "error TS" | wc -l

// @ts-expect-error -- conocido seguro, se arreglará en JIRA-123
const value = riskyFunction();

{
  rules: {
    "@typescript-eslint/no-floating-promises": "error",
    "@typescript-eslint/no-misused-promises": "error",
    "@typescript-eslint/await-thenable": "error",
    "@typescript-eslint/prefer-nullish-coalescing": "warn",
  }
}

Relacionado

• Reglas ESLint Esenciales — Reglas ESLint que complementan TypeScript estricto
• Plugins ESLint — Configuración del plugin @typescript-eslint
• Linting en CI/CD — ejecutar tsc --noEmit en CI
• Configuración de ESLint para Next.js — configuración base de ESLint