Respuesta.

Historia de la pregunta

TypeScript fue diseñado originalmente con la posibilidad de una transición fluida desde JavaScript, por lo que, de forma predeterminada, las variables o parámetros sin un tipo explícito obtienen el tipo any. Esto facilitaba la migración, pero disminuía las ventajas de la tipificación estática. Para aumentar la fiabilidad y la previsibilidad del código, el equipo de TypeScript implementó la bandera del compilador noImplicitAny, que requiere especificar explícitamente los tipos o permitir que TypeScript los infiera correctamente.

Problema

Cuando noImplicitAny está desactivado, los desarrolladores pueden pasar por alto accidentalmente la especificación del tipo para una variable, un parámetro o el valor de retorno de una función. Esto hace que el código sea menos seguro y dificulta la reestructuración: cualquier error relacionado con tipos no se detecta en tiempo de compilación, sino que se manifiesta solo en tiempo de ejecución.

Solución

Activar noImplicitAny en el archivo tsconfig.json obliga al compilador de TypeScript a lanzar un error en cada uso implícito del tipo any. Esto requiere que los desarrolladores presten atención a los tipos, hace que los procesos de reestructuración sean menos arriesgados y el código en sí sea más fiable.

Ejemplo de código:

// tsconfig.json
{
  "compilerOptions": {
    "noImplicitAny": true
  }
}

// Ejemplo de función sin especificar el tipo del parámetro
function printUser(user) {
  console.log(user.name); // Error de compilación si no se especifica el tipo
}

// Correcto:
function printUser(user: { name: string }) {
  console.log(user.name);
}

Características clave:

Requiere especificar tipos en cualquier lugar ambiguo.
Permite detectar la mayor parte de los errores de tipos en tiempo de compilación.
Proporciona una alta previsibilidad y seguridad del código en grandes proyectos.

Preguntas engañosas.

¿La activación de noImplicitAny siempre evita todos los posibles errores de tipos en el proyecto?

No, esta bandera solo elimina los any implícitos. El uso explícito de any sigue estando permitido. Para una protección completa, es recomendable restringir también el any explícito a través de linting y revisiones.

Si el tipo se infiere automáticamente, ¿noImplicitAny sigue generando errores?

No, si TypeScript pudo inferir correctamente el tipo (por ejemplo, a través de la inicialización), no habrá error. Por ejemplo:

let n = 123; // Tipo number, no any

¿La activación de strict activa automáticamente noImplicitAny?

Sí, la bandera strict activa numerosas comprobaciones estrictas, incluido noImplicitAny. Pero se puede desactivar manualmente si es necesario.

Errores comunes y anti-patrones

Dejar any explícito en muchos lugares — se pierde el sentido de la tipificación estricta.
En un código extenso, no ejecutar el proyecto con noImplicitAny, confiando en "ya veremos" — muchas errores ocultos.
Añadir tipos "de cualquier manera, solo para compilar", sin pensar en la corrección.

Ejemplo de la vida real

Caso negativo

En el proyecto noImplicitAny está desactivado, la mayoría de los manejadores de API aceptan parámetros sin tipo explícito. Al implementar nuevas lógicas de negocio, los desarrolladores cometen errores en los nombres de las propiedades, pero los errores solo salen a la luz en producción.

Ventajas:

Inicio de código simple y rápido.
Más fácil de migrar desde JS.

Desventajas:

En producción aparecen errores que podrían haberse encontrado estáticamente.
La reestructuración y la escalabilidad se complican.

Caso positivo

Después de activar noImplicitAny, todo el código fue reestructurado gradualmente, eliminándose los any implícitos. Se comenzó a utilizar un editor con resaltado de tipos y autocompletado. Los nuevos errores que aparecían se corregían de inmediato en la fase de construcción.