Pega un tsconfig y mira qué comprobaciones están activas de verdad. strict enciende nueve opciones y deja otras ocho apagadas, cada una con el código que deja pasar. No se sube nada.

Tu tsconfig, o solo el bloque compilerOptions

Prueba con:

strict: true
Comprobaciones que cubre strict: 8 / 9
Comprobaciones que no cubre: 0 / 8

Desactivadas a mano

Están escritas como false en tu configuración, y lo explícito gana a strict. El compilador no se quejará de que hayas pedido las dos cosas.

noImplicitAny

Lo que activa strict

Exactamente estas nueve, leídas del compilador y no de un artículo. Ponerlas tú mismo sobra, salvo que sea para apagar alguna.

noImplicitAnydesactivada · puesta en tu configuración
strictNullChecksactivada · por strict
strictFunctionTypesactivada · por strict
strictBindCallApplyactivada · por strict
strictPropertyInitializationactivada · por strict
strictBuiltinIteratorReturnactivada · por strict
noImplicitThisactivada · por strict
useUnknownInCatchVariablesactivada · por strict
alwaysStrictactivada · por strict

Lo que strict deja fuera

Cada una de estas detecta algo que strict acepta. En cada fila verás un programa que compila limpio con strict y falla en cuanto se activa la opción.

noUncheckedIndexedAccessdesactivada · no pedida
strict acepta esto · esta opción lo rechaza con el error TS2322
```
const xs: string[] = []
const first: string = xs[0]
export { first }
```
exactOptionalPropertyTypesdesactivada · no pedida
strict acepta esto · esta opción lo rechaza con el error TS2375
```
type User = { nickname?: string }
const u: User = { nickname: undefined }
export { u }
```
noImplicitOverridedesactivada · no pedida
strict acepta esto · esta opción lo rechaza con el error TS4114
```
class Base { save() {} }
class Row extends Base { save() {} }
export { Row }
```
noPropertyAccessFromIndexSignaturedesactivada · no pedida
strict acepta esto · esta opción lo rechaza con el error TS4111
```
type Env = { [key: string]: string }
declare const env: Env
export const url = env.DATABASE_URL
```

noFallthroughCasesInSwitchdesactivada · no pedida

strict acepta esto · esta opción lo rechaza con el error TS7029

export function rank(n: number) {
  switch (n) {
    case 1:
      console.log("one")
    case 2:
      return 2
  }
  return 0
}

noImplicitReturnsdesactivada · no pedida
strict acepta esto · esta opción lo rechaza con el error TS7030
```
export function sign(n: number) {
  if (n > 0) {
    return "positive"
  }
}
```
noUnusedLocalsdesactivada · no pedida
strict acepta esto · esta opción lo rechaza con el error TS6133
```
export function total(n: number) {
  const unused = n * 2
  return n
}
```
noUnusedParametersdesactivada · no pedida
strict acepta esto · esta opción lo rechaza con el error TS6133
```
export function greet(name: string, title: string) {
  return name
}
```

TypeScript 5.9.3

Se lee del compilador de TypeScript con el que se construye este sitio, así que la lista sigue al compilador y no al revés.

También disponible en: English · Português · Français · العربية

Qué activa de verdad el modo strict de TypeScript

Las nueve opciones que cubre strict, las ocho que no, y el código que cada una deja pasar, comprobado compilando y no citando.

¿Qué hace strict: true?

Poner strict en true dentro del tsconfig es un atajo: enciende un grupo fijo de opciones sueltas del compilador, no es una comprobación en sí misma. En TypeScript 5.9 ese grupo tiene exactamente nueve miembros: noImplicitAny, strictNullChecks, strictFunctionTypes, strictBindCallApply, strictPropertyInitialization, strictBuiltinIteratorReturn, noImplicitThis, useUnknownInCatchVariables y alwaysStrict.

Merece la pena leer esa lista del compilador y no de un artículo, porque crece. strictBuiltinIteratorReturn se añadió en TypeScript 5.6 y casi todos los textos siguen describiendo strict como siete u ocho opciones. Esta página saca la lista de las declaraciones de opciones del propio compilador, así que sigue a TypeScript y no al revés.

Lo importante es lo que no está en el grupo. TypeScript tiene otras ocho opciones que atrapan errores reales y que strict no toca, entre ellas noUncheckedIndexedAccess, exactOptionalPropertyTypes y noImplicitOverride. Un proyecto con strict activado no es un proyecto con todas las comprobaciones activadas, y la diferencia es mayor de lo que casi nadie espera.

Cómo usarlo

Pega tu tsconfig, o solo el bloque compilerOptions. Los comentarios y las comas finales no son problema: un tsconfig es JSONC, no JSON, y esto lo lee como lo lee tsc. Vale tanto el archivo entero como un objeto de opciones suelto.
Mira los dos recuentos. Cuántas de las nueve que cubre strict están activas, y cuántas de las ocho que no cubre. Lo que hayas apagado a mano aparece aparte, porque lo explícito gana a strict y nadie te avisa.
Fíjate en los ejemplos de código de las ocho. Cada uno es un programa que compila limpio con strict activado y falla en cuanto se añade esa opción. Copia la configuración más estricta con el botón si quieres las diecisiete.

Las ocho comprobaciones que strict deja fuera

Cada opción de esa segunda lista viene aquí con un programa que demuestra el hueco, y cada uno de esos programas se compiló dos veces al construir esta página: una con strict, donde no puede dar ningún error, y otra con la opción añadida, donde tiene que fallar. Un ejemplo solo aparece porque el compilador dio los dos resultados, así que la afirmación es una medición y no una opinión.

La primera con la que te topas es noUncheckedIndexedAccess. Con strict, leer xs[0] de un array de strings te da un string, aunque el array pueda estar vacío y el valor pueda ser undefined: la indexación simplemente miente al respecto. Al activar la opción el tipo pasa a ser string | undefined y el compilador empieza a pedirte que compruebes. Es la mayor fuente de undefined en tiempo de ejecución en bases de código que por lo demás son estrictas.

exactOptionalPropertyTypes es la más sutil. Con un tipo { nickname?: string }, strict acepta tan tranquilo { nickname: undefined }, así que desaparece la diferencia entre una propiedad ausente y una presente con valor undefined, cosa que importa muchísimo si ese objeto va a serializarse o a esparcirse sobre una fila de base de datos. noImplicitOverride pilla el método de una subclase que tapa sin querer el del padre, que es la forma en que un renombrado deja de llamar en silencio a lo que creías. noPropertyAccessFromIndexSignature devuelve env.DATABASE_URL a env["DATABASE_URL"], de modo que una errata en el nombre de una variable de entorno deja de pasar por string.

Las cuatro restantes tienen menos que ver con los tipos y más con el código muerto o inalcanzable: un case de un switch que se cuela al siguiente, una función que devuelve un valor por un camino y nada por otro, y variables locales o parámetros que nadie lee.

Límites honestos

Lo explícito gana a strict, en los dos sentidos, y esa es la parte que muerde en silencio. Escribir strict en true junto a noImplicitAny en false silencia de verdad los errores de any implícito: el compilador acepta la combinación sin decir nada, y una configuración heredada de un proyecto viejo puede arrastrar un agujero así durante años. Esta página los lista aparte, y tsc --showConfig te lo confirma si quieres una segunda opinión.

No sigue extends. Un tsconfig que hereda de un archivo base —el preset de un framework, un paquete compartido— es solo la mitad de la historia, y esta página lee lo que pegas en lugar de resolver la cadena. Ejecuta tsc --showConfig en el proyecto para ver el resultado resuelto y pega eso aquí.

La lista va atada a una versión de TypeScript, que aparece junto al botón de copiar. Se añaden opciones: si tu compilador es más nuevo que el de esta página, puede conocer alguna que aquí no está. Por eso la lista se genera del compilador en vez de escribirse a mano, y por eso la versión está en la página y no dada por supuesta.

Y activarlo todo no es automáticamente lo correcto. noUnusedLocals en particular pelea con el trabajo a medio hacer, y varios equipos la dejan en el editor y no en la compilación. La página te enseña dónde estás y qué cuesta cada opción; no finge que la respuesta sea siempre que sí.

¿Por qué es gratis?

Todo ocurre en tu navegador. Un tsconfig puede nombrar rutas internas, registros de paquetes y la estructura del proyecto, y nada de eso se envía a ninguna parte: el archivo no sale de la pestaña.

No hay coste de servidor que recuperar, así que no hay cuenta, ni límite, ni marca de agua.